script(1) improvement

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

script(1) improvement

Soumendra Ganguly
Hello, OpenBSD!
       I am using script(1) to complement a program that I am writing.
However, the current OpenBSD version of script(1) is very old [ based
on NetBSD script(1) version 1.3 ]. It does not have the [-r] and [-p]
options that the current NetBSD version [ 1.21 ] does. FreeBSD's
script(1) also has this functionality; util-linux provides similar
functionality in the form of script(1)+scriptreplay(1). Please
consider merging the current NetBSD version into OpenBSD.

Note: There is a small bug that the FreeBSD and NetBSD versions have,
but I have submitted PRs for them; therefore, we can wait till NetBSD
patches their version! NetBSD PR:
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=55529.

Thank you.
Soumendra Ganguly

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Theo de Raadt-2
Soumendra Ganguly <[hidden email]> wrote:

> Hello, OpenBSD!
>        I am using script(1) to complement a program that I am writing.
> However, the current OpenBSD version of script(1) is very old [ based
> on NetBSD script(1) version 1.3 ].

First off, it is not old.  We don't automatically grab changes from
completely distinct.  It has been completely seperate code for over 20
years.  Once in a while, an idea will show up, and get copied.

> It does not have the [-r] and [-p]
> options that the current NetBSD version [ 1.21 ] does. FreeBSD's
> script(1) also has this functionality; util-linux provides similar
> functionality in the form of script(1)+scriptreplay(1).

I am horrified by what I see; I could never see myself needing that
type of functionality, since it is so fragile.

A replay of a sequence of previously issued commands will work fine for
very small steps, but when used for increasingly large missions it
quickly turns into a shitshow.

The sequences captured will not generally contain error condition
checking along the way.  Therefore, input will be continue to be
injected even if a ecommand in the replay-case behaves different.

This is effectively the same as software which is written without checking
error returns at every step, we encourage all re-useable software to be
written with error checks at every step, why add a subsystem which goes
against the grain?

I think we should discourage new systems which behave like that.

> Please consider merging the current NetBSD version into OpenBSD.

Sorry, that is not how the development process in this project works.

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
Theo,
   Thank you for the feedback. I can understand why some of that
functionality might be unnecessary if one only needs a hard copy of
the terminal session. That is why [-r], [-p] are not applied by
default.

My patch for NetBSD script(1) has been accepted now. I will submit a
PR to OpenBSD soon.

Thank you.
Soumendra

On 8/1/20, Theo de Raadt <[hidden email]> wrote:

> Soumendra Ganguly <[hidden email]> wrote:
>
>> Hello, OpenBSD!
>>        I am using script(1) to complement a program that I am writing.
>> However, the current OpenBSD version of script(1) is very old [ based
>> on NetBSD script(1) version 1.3 ].
>
> First off, it is not old.  We don't automatically grab changes from
> completely distinct.  It has been completely seperate code for over 20
> years.  Once in a while, an idea will show up, and get copied.
>
>> It does not have the [-r] and [-p]
>> options that the current NetBSD version [ 1.21 ] does. FreeBSD's
>> script(1) also has this functionality; util-linux provides similar
>> functionality in the form of script(1)+scriptreplay(1).
>
> I am horrified by what I see; I could never see myself needing that
> type of functionality, since it is so fragile.
>
> A replay of a sequence of previously issued commands will work fine for
> very small steps, but when used for increasingly large missions it
> quickly turns into a shitshow.
>
> The sequences captured will not generally contain error condition
> checking along the way.  Therefore, input will be continue to be
> injected even if a ecommand in the replay-case behaves different.
>
> This is effectively the same as software which is written without checking
> error returns at every step, we encourage all re-useable software to be
> written with error checks at every step, why add a subsystem which goes
> against the grain?
>
> I think we should discourage new systems which behave like that.
>
>> Please consider merging the current NetBSD version into OpenBSD.
>
> Sorry, that is not how the development process in this project works.
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Stuart Henderson
What does the replay feature actually do? Does it re-enter the commands
or just display the console output (like "cat typescript", but slower)?


On 2020/08/01 22:23, Soumendra Ganguly wrote:

> Theo,
>    Thank you for the feedback. I can understand why some of that
> functionality might be unnecessary if one only needs a hard copy of
> the terminal session. That is why [-r], [-p] are not applied by
> default.
>
> My patch for NetBSD script(1) has been accepted now. I will submit a
> PR to OpenBSD soon.
>
> Thank you.
> Soumendra
>
> On 8/1/20, Theo de Raadt <[hidden email]> wrote:
> > Soumendra Ganguly <[hidden email]> wrote:
> >
> >> Hello, OpenBSD!
> >>        I am using script(1) to complement a program that I am writing.
> >> However, the current OpenBSD version of script(1) is very old [ based
> >> on NetBSD script(1) version 1.3 ].
> >
> > First off, it is not old.  We don't automatically grab changes from
> > completely distinct.  It has been completely seperate code for over 20
> > years.  Once in a while, an idea will show up, and get copied.
> >
> >> It does not have the [-r] and [-p]
> >> options that the current NetBSD version [ 1.21 ] does. FreeBSD's
> >> script(1) also has this functionality; util-linux provides similar
> >> functionality in the form of script(1)+scriptreplay(1).
> >
> > I am horrified by what I see; I could never see myself needing that
> > type of functionality, since it is so fragile.
> >
> > A replay of a sequence of previously issued commands will work fine for
> > very small steps, but when used for increasingly large missions it
> > quickly turns into a shitshow.
> >
> > The sequences captured will not generally contain error condition
> > checking along the way.  Therefore, input will be continue to be
> > injected even if a ecommand in the replay-case behaves different.
> >
> > This is effectively the same as software which is written without checking
> > error returns at every step, we encourage all re-useable software to be
> > written with error checks at every step, why add a subsystem which goes
> > against the grain?
> >
> > I think we should discourage new systems which behave like that.
> >
> >> Please consider merging the current NetBSD version into OpenBSD.
> >
> > Sorry, that is not how the development process in this project works.
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
Stuart,
   Sorry. I should have clarified. It does not re-enter the commands.
If [-r] is used, then extra timing information is recorded into the
typescript file, which can later be used by [-p] to replay the session
[ like a video ] on the terminal. The patch to which I was referring
enables proper curses playback; therefore, one can now watch an
editing session on vi being replayed at a later time. While "cat
typescript | less" suffices in many cases, proper timing information
is necessary for the playback of curses sessions.

I was not requesting a feature which re-runs the commands; although
util-linux seems to have a program called "scriptlive" which does
exactly that.

Thank you.
Soumendra

On 8/2/20, Stuart Henderson <[hidden email]> wrote:

> What does the replay feature actually do? Does it re-enter the commands
> or just display the console output (like "cat typescript", but slower)?
>
>
> On 2020/08/01 22:23, Soumendra Ganguly wrote:
>> Theo,
>>    Thank you for the feedback. I can understand why some of that
>> functionality might be unnecessary if one only needs a hard copy of
>> the terminal session. That is why [-r], [-p] are not applied by
>> default.
>>
>> My patch for NetBSD script(1) has been accepted now. I will submit a
>> PR to OpenBSD soon.
>>
>> Thank you.
>> Soumendra
>>
>> On 8/1/20, Theo de Raadt <[hidden email]> wrote:
>> > Soumendra Ganguly <[hidden email]> wrote:
>> >
>> >> Hello, OpenBSD!
>> >>        I am using script(1) to complement a program that I am writing.
>> >> However, the current OpenBSD version of script(1) is very old [ based
>> >> on NetBSD script(1) version 1.3 ].
>> >
>> > First off, it is not old.  We don't automatically grab changes from
>> > completely distinct.  It has been completely seperate code for over 20
>> > years.  Once in a while, an idea will show up, and get copied.
>> >
>> >> It does not have the [-r] and [-p]
>> >> options that the current NetBSD version [ 1.21 ] does. FreeBSD's
>> >> script(1) also has this functionality; util-linux provides similar
>> >> functionality in the form of script(1)+scriptreplay(1).
>> >
>> > I am horrified by what I see; I could never see myself needing that
>> > type of functionality, since it is so fragile.
>> >
>> > A replay of a sequence of previously issued commands will work fine for
>> > very small steps, but when used for increasingly large missions it
>> > quickly turns into a shitshow.
>> >
>> > The sequences captured will not generally contain error condition
>> > checking along the way.  Therefore, input will be continue to be
>> > injected even if a ecommand in the replay-case behaves different.
>> >
>> > This is effectively the same as software which is written without
>> > checking
>> > error returns at every step, we encourage all re-useable software to be
>> > written with error checks at every step, why add a subsystem which goes
>> > against the grain?
>> >
>> > I think we should discourage new systems which behave like that.
>> >
>> >> Please consider merging the current NetBSD version into OpenBSD.
>> >
>> > Sorry, that is not how the development process in this project works.
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
Theo,
      The replay feature does not make script(1) re-enter the
commands. It simply replays them on the terminal as if it were a video
[ like "cat typescript" but slower ]. It is particularly useful if
someone wants to replay [ not re-run ] a curses session [ such as a
game or an editing session on vi ].

I ended up writing my own program that has all the features that I
wanted. However, there are a few small changes that I propose for
usr.bin/script/script.c. I have not set up my VM to be able to use
sendbug(1). I sent my patch in a separate email with the following as
subject.

"[PATCH] script(1): Change openpty arguments if stdin is not a tty +
other small changes"

Thank you.

On 8/2/20, Soumendra Ganguly <[hidden email]> wrote:

> Stuart,
>    Sorry. I should have clarified. It does not re-enter the commands.
> If [-r] is used, then extra timing information is recorded into the
> typescript file, which can later be used by [-p] to replay the session
> [ like a video ] on the terminal. The patch to which I was referring
> enables proper curses playback; therefore, one can now watch an
> editing session on vi being replayed at a later time. While "cat
> typescript | less" suffices in many cases, proper timing information
> is necessary for the playback of curses sessions.
>
> I was not requesting a feature which re-runs the commands; although
> util-linux seems to have a program called "scriptlive" which does
> exactly that.
>
> Thank you.
> Soumendra
>
> On 8/2/20, Stuart Henderson <[hidden email]> wrote:
>> What does the replay feature actually do? Does it re-enter the commands
>> or just display the console output (like "cat typescript", but slower)?
>>
>>
>> On 2020/08/01 22:23, Soumendra Ganguly wrote:
>>> Theo,
>>>    Thank you for the feedback. I can understand why some of that
>>> functionality might be unnecessary if one only needs a hard copy of
>>> the terminal session. That is why [-r], [-p] are not applied by
>>> default.
>>>
>>> My patch for NetBSD script(1) has been accepted now. I will submit a
>>> PR to OpenBSD soon.
>>>
>>> Thank you.
>>> Soumendra
>>>
>>> On 8/1/20, Theo de Raadt <[hidden email]> wrote:
>>> > Soumendra Ganguly <[hidden email]> wrote:
>>> >
>>> >> Hello, OpenBSD!
>>> >>        I am using script(1) to complement a program that I am
>>> >> writing.
>>> >> However, the current OpenBSD version of script(1) is very old [ based
>>> >> on NetBSD script(1) version 1.3 ].
>>> >
>>> > First off, it is not old.  We don't automatically grab changes from
>>> > completely distinct.  It has been completely seperate code for over 20
>>> > years.  Once in a while, an idea will show up, and get copied.
>>> >
>>> >> It does not have the [-r] and [-p]
>>> >> options that the current NetBSD version [ 1.21 ] does. FreeBSD's
>>> >> script(1) also has this functionality; util-linux provides similar
>>> >> functionality in the form of script(1)+scriptreplay(1).
>>> >
>>> > I am horrified by what I see; I could never see myself needing that
>>> > type of functionality, since it is so fragile.
>>> >
>>> > A replay of a sequence of previously issued commands will work fine
>>> > for
>>> > very small steps, but when used for increasingly large missions it
>>> > quickly turns into a shitshow.
>>> >
>>> > The sequences captured will not generally contain error condition
>>> > checking along the way.  Therefore, input will be continue to be
>>> > injected even if a ecommand in the replay-case behaves different.
>>> >
>>> > This is effectively the same as software which is written without
>>> > checking
>>> > error returns at every step, we encourage all re-useable software to
>>> > be
>>> > written with error checks at every step, why add a subsystem which
>>> > goes
>>> > against the grain?
>>> >
>>> > I think we should discourage new systems which behave like that.
>>> >
>>> >> Please consider merging the current NetBSD version into OpenBSD.
>>> >
>>> > Sorry, that is not how the development process in this project works.
>>> >
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Theo de Raadt-2
Soumendra Ganguly <[hidden email]> wrote:

> Theo,
>       The replay feature does not make script(1) re-enter the
> commands. It simply replays them on the terminal as if it were a video
> [ like "cat typescript" but slower ]. It is particularly useful if
> someone wants to replay [ not re-run ] a curses session [ such as a
> game or an editing session on vi ].
>
> I ended up writing my own program that has all the features that I
> wanted. However, there are a few small changes that I propose for
> usr.bin/script/script.c. I have not set up my VM to be able to use
> sendbug(1). I sent my patch in a separate email with the following as
> subject.

well, that's not the purpose of script, to have a special mode, creating
special files, which only it can can handle

the name for when things like that get added is "scope creep".

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Stefan Hagen-2
In reply to this post by Soumendra Ganguly
Soumendra Ganguly wrote:
> It is particularly useful if someone wants to replay [ not re-run ] a
> curses session [ such as a game or an editing session on vi ].

Have you tried textproc/asciinema?

$ asciinema rec demo.cast
# do something ncurses or not; stop with ctrl+d
$ asciinema play demo.cast

Best Regards,
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
Stefan,
       I had heard about asciinema before [
https://intoli.com/blog/terminal-recorders/ mentions a ton of other
terminal recorders ]. asciinema is great. I had not heard about
textproc before. Thank you very much for the information!

My original intention was to know HOW these programs record the
terminal. I have now written my own C program [ not released yet ]
that does what I want while not using the Linux specific signalfd api
that the util-linux version does. That way, it can run on many
operating systems. Since the Linux, FreeBSD, and NetBSD versions of
script have the replay feature, my OCD tempted me to request it for
OpenBSD as well :D However, I understand Theo's message about "scope
creep".

Thank you again.
Soumendra.

On 8/9/20, Stefan Hagen <[hidden email]> wrote:

> Soumendra Ganguly wrote:
>> It is particularly useful if someone wants to replay [ not re-run ] a
>> curses session [ such as a game or an editing session on vi ].
>
> Have you tried textproc/asciinema?
>
> $ asciinema rec demo.cast
> # do something ncurses or not; stop with ctrl+d
> $ asciinema play demo.cast
>
> Best Regards,
> Stefan
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
I am trying to make my own code better + shorter + more portable.
If/when anyone has time, can you please explain the following to me so
that I do not make embarrassing claims like the one that I made on the
other patch thread? :D

Revision 1.33 of script(1) changes

(void)tcgetattr(STDIN_FILENO, &tt);
        (void)ioctl(STDIN_FILENO, TIOCGWINSZ, &win);

to

if (isatty(0)) {
                if (tcgetattr(STDIN_FILENO, &tt) == 0 &&
                    ioctl(STDIN_FILENO, TIOCGWINSZ, &win) == 0)
                        istty = 1;
}

based on the fact that tty operations should not be performed on stdin
if it is not a tty [ maybe it is a regular file ]. This observation
was made by [hidden email]. I claim that only

                if (tcgetattr(STDIN_FILENO, &tt) == 0 &&
                    ioctl(STDIN_FILENO, TIOCGWINSZ, &win) == 0)
                        istty = 1;

would have been sufficient because tcgetattr will fail with errno ==
ENOTTY if stdin is not a tty. Am I wrong? This claim is true on
NetBSD/FreeBSD because their versions of isatty simply make a call to
tcgetattr to see it it succeeds. However, the OpenBSD version [
/lib/libc/gen/isatty.c ] calls fcntl with F_ISATTY, which also, like
tcgetattr, sets errno to ENOTTY if the fd is not a tty [ sys_fcntl()
from /sys/kern/kern_descrip.c ].

Additional note: tcgetattr calls ioctl with TIOCGETA [
/lib/libc/termios/tcgetattr.c  and ttioctl() from /sys/kern/tty.c ].

Thank you very much for your patience.
Soumendra


On 8/9/20, Soumendra Ganguly <[hidden email]> wrote:

> Stefan,
>        I had heard about asciinema before [
> https://intoli.com/blog/terminal-recorders/ mentions a ton of other
> terminal recorders ]. asciinema is great. I had not heard about
> textproc before. Thank you very much for the information!
>
> My original intention was to know HOW these programs record the
> terminal. I have now written my own C program [ not released yet ]
> that does what I want while not using the Linux specific signalfd api
> that the util-linux version does. That way, it can run on many
> operating systems. Since the Linux, FreeBSD, and NetBSD versions of
> script have the replay feature, my OCD tempted me to request it for
> OpenBSD as well :D However, I understand Theo's message about "scope
> creep".
>
> Thank you again.
> Soumendra.
>
> On 8/9/20, Stefan Hagen <[hidden email]> wrote:
>> Soumendra Ganguly wrote:
>>> It is particularly useful if someone wants to replay [ not re-run ] a
>>> curses session [ such as a game or an editing session on vi ].
>>
>> Have you tried textproc/asciinema?
>>
>> $ asciinema rec demo.cast
>> # do something ncurses or not; stop with ctrl+d
>> $ asciinema play demo.cast
>>
>> Best Regards,
>> Stefan
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
In reply to this post by Soumendra Ganguly
Raf,
    Aah. Got it. I thought textproc was a separate program [ n00b ].
Sadly, I am only running OpenBSD in a vm currently to examine the code
of script(1). I truly appreciate the fact that you clarified this.

Soumendra

On 8/9/20, Raf Czlonka <[hidden email]> wrote:

> On Sun, Aug 09, 2020 at 10:07:47AM BST, Soumendra Ganguly wrote:
>> I had not heard about textproc before.
>>
>
> Hi Soumendra,
>
> textproc[0] (text processing) below is a category which asciinema[1]
> port belongs to as well as its location in the ports CVS tree.
>
> [0]
> https://urldefense.com/v3/__https://cvsweb.openbsd.org/ports/textproc/__;!!KwNVnqRv!Xv3f6EILrcRCJugsU_NGlemM80MJOcq2D9L_MIx9X6925G5UypnFxbM35CG3eTy4$
>
> [1]
> https://urldefense.com/v3/__https://cvsweb.openbsd.org/ports/textproc/asciinema/__;!!KwNVnqRv!Xv3f6EILrcRCJugsU_NGlemM80MJOcq2D9L_MIx9X6925G5UypnFxbM35P03siPW$
>
>
> Regards,
>
> Raf
>
>> On 8/9/20, Stefan Hagen <[hidden email]> wrote:
>> >
>> > Have you tried textproc/asciinema?
>

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Theo de Raadt-2
In reply to this post by Soumendra Ganguly
Soumendra Ganguly <[hidden email]> wrote:

> based on the fact that tty operations should not be performed on stdin
> if it is not a tty [ maybe it is a regular file ]. This observation
> was made by [hidden email]. I claim that only
>
> if (tcgetattr(STDIN_FILENO, &tt) == 0 &&
>    ioctl(STDIN_FILENO, TIOCGWINSZ, &win) == 0)
> istty = 1;
>
> would have been sufficient because tcgetattr will fail with errno ==
> ENOTTY if stdin is not a tty. Am I wrong? This claim is true on
> NetBSD/FreeBSD because their versions of isatty simply make a call to
> tcgetattr to see it it succeeds. However, the OpenBSD version [
> /lib/libc/gen/isatty.c ] calls fcntl with F_ISATTY, which also, like
> tcgetattr, sets errno to ENOTTY if the fd is not a tty [ sys_fcntl()
> from /sys/kern/kern_descrip.c ].
>
> Additional note: tcgetattr calls ioctl with TIOCGETA [
> /lib/libc/termios/tcgetattr.c  and ttioctl() from /sys/kern/tty.c ].

isatty() using fcntl+F_ISATTY rather than ioctl was to permit
pledge-heavy programs to eliminate all ioctl use.  isatty() was the most
significant hidden ioctl() system call use in some important programs,
so I changed introduced F_ISATTY, changed libc isatty(), and then those
specific programs could be avoid ioctl() usage and become simpler.

But if I undestand correctly this program always does ioctl afterwards,
and when those ioctl indicate ENOTTY, it does the right thing, so why
bother calling isatty()?  I doubt it can be pledged further, to entirely
avoid ioctl, without increasing the complexity excessively, so why
bother adding additional conditions?

I've given up trying to follow all your proposals, because there are so
many, and they are so mixed up.  I have completely lost track of what
problem you are trying to solve (you may see one real problem, but you
keep jumping around with small nits which others don't see).  I am
started wondering if you are only doing this to leave your mark. Sorry,
that's my take on it.  I'm done.

Reply | Threaded
Open this post in threaded view
|

Re: script(1) improvement

Soumendra Ganguly
Yes. You are correct. In the back of my mind, I did want to leave a
small mark [ OCD ].

However, I was also trying to justify removing, from my own code, all
isatty instances that are immediately followed by tcgetattr [ again,
OCD ]. The fact that I understood the isatty situation correctly is
valuable enough for me. Thank you for taking the time to verify.

If it ain't broke, don't fix it I guess? A change to the OpenBSD
script(1) source is not necessary unless some day someone decides to
make fdopenpty in src/lib/libutil/pty.c fail due to TCSAFLUSH and
TIOCSWINSZ failures.

Also, I kind of did realize why isatty was avoiding ioctl. Thank you
for verifying anyway. I am truly impressed by how precise OpenBSD
codebase is. Who would not want to leave their mark on it?

Officially "closing" this "issue".

Soumendra

Additional note: The replay feature in the other BSDs and util-linux
did have terminal post-processing related bugs in them [ now fixed ].

On 8/10/20, Theo de Raadt <[hidden email]> wrote:

> Soumendra Ganguly <[hidden email]> wrote:
>
>> based on the fact that tty operations should not be performed on stdin
>> if it is not a tty [ maybe it is a regular file ]. This observation
>> was made by [hidden email]. I claim that only
>>
>> if (tcgetattr(STDIN_FILENO, &tt) == 0 &&
>>    ioctl(STDIN_FILENO, TIOCGWINSZ, &win) == 0)
>> istty = 1;
>>
>> would have been sufficient because tcgetattr will fail with errno ==
>> ENOTTY if stdin is not a tty. Am I wrong? This claim is true on
>> NetBSD/FreeBSD because their versions of isatty simply make a call to
>> tcgetattr to see it it succeeds. However, the OpenBSD version [
>> /lib/libc/gen/isatty.c ] calls fcntl with F_ISATTY, which also, like
>> tcgetattr, sets errno to ENOTTY if the fd is not a tty [ sys_fcntl()
>> from /sys/kern/kern_descrip.c ].
>>
>> Additional note: tcgetattr calls ioctl with TIOCGETA [
>> /lib/libc/termios/tcgetattr.c  and ttioctl() from /sys/kern/tty.c ].
>
> isatty() using fcntl+F_ISATTY rather than ioctl was to permit
> pledge-heavy programs to eliminate all ioctl use.  isatty() was the most
> significant hidden ioctl() system call use in some important programs,
> so I changed introduced F_ISATTY, changed libc isatty(), and then those
> specific programs could be avoid ioctl() usage and become simpler.
>
> But if I undestand correctly this program always does ioctl afterwards,
> and when those ioctl indicate ENOTTY, it does the right thing, so why
> bother calling isatty()?  I doubt it can be pledged further, to entirely
> avoid ioctl, without increasing the complexity excessively, so why
> bother adding additional conditions?
>
> I've given up trying to follow all your proposals, because there are so
> many, and they are so mixed up.  I have completely lost track of what
> problem you are trying to solve (you may see one real problem, but you
> keep jumping around with small nits which others don't see).  I am
> started wondering if you are only doing this to leave your mark. Sorry,
> that's my take on it.  I'm done.
>