Subject: Re: Feedback needed on proposed cygwin feature
From: [email-masked] (Kimon Kontovasilis)

2 Dec 1997 05:48:17 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
To: [email-masked]
Cc: [email-masked]

Dear Chris,

> 
> I have recently provided a patch to Cygnus to provide control of various
> environment variable settings on a program by program basis.
> 
> Geoffrey has asked that I get feedback on my changes to see if they are
> something that is useful to the list as a whole.
> 

Thank you for your efforts on this. Here is my feedback, as requested:

> My changes cause a program to read the registry for options settings prior
> to reading settings from the environment.  So, for instance, you can do
> something like this:
> 
> 	cygwin -o 'c:\bin\bash.exe' binmode notitle
> 
> That will set options in the registry which will cause bash to always
> use 'binmode' as its default and to never modify the title bar.
> 

I find the feature a good idea. I think, however, that there should be
a `default' registry entry, applying to programs not explicitly
registered; this could be arranged, for example, by

	`cygwin -d binmode title'.

(Without the default entry, a user will have to register each and every
program individually, if environment variables are to be dispensed with.)

Another issue I see important in connection with registry entries for
specific programs (like the `bash' example you gave) is they way the
linkage between the program and the settings is specified. If the program
is identified through its full pathname (as the example on bash above
indicates) then dangerous things may happen. For example, if the program is
moved to a different directory, the association will be broken and the
program will start using the default settings, something obviously
unsatisfactory. (This problem does not arise with environment variables.)

Should the linkage between program and settings use only the program's
basename? Well, this would remove the side-effects following relocation
of a file, but would force two programs of the same name, in different
directories, to use the same settings (and no way to override this in the
registry would be possible). This is less of an issue to me.

Even this arrangement may not be entirely adequate; for, if the program reads
the settings using argv[0] as the key to search (speculation here, since
I don't know any implementation details) there will be problems in Win95, when
the standard shell (COMMAND.COM) is used. This shell sets argv[0] so that the
individual path components have their 8.3 `short-form' names (although the
cygnus startup code replaces /-separators for \-ones). For example, on my
system the `find' program gets an argv[0] equal to

	/GNUWIN32/H-I386~1/BIN/FIND.EXE

when run under COMMAND.COM. Then, two, otherwise identical registry entries,
one for find.exe and one for FIND.EXE might be required. This is, of course,
unsatisfactory.

> Here are the pros and cons as we see them so far:
> 
> 1) Registry
> 
>     Pros:
> 
> 	a)  Don't need to mess with system environment variables.

Something nice indeed. Furthermore, the variables may always be used
to override things, on a per-session or a per-run basis.

> 
> 	b)  Allows pinpoint control of what program gets what options, e.g.
> 	    setting `tty' on for bash means that bash always starts with
> 	    a true /dev/tty.  Other programs run from the command line will
> 	    not also use tty handling as seen when using the CYGWIN_TTY
> 	    environment variable.
> 

Something also nice and not possible with env. vars. See, however, my
considerations on this feature, expressed above.

> 	c)  "Solves" the problem of programs, ported from UNIX, which need
> 	    to use `binmode' by default.
> 
A small issue here arises: what are the semantics of both using [no]binmode
and the mount-settings for various directories? A possible (and preferred
to me) choice is to have a program disregard mount-settings if a
program-specific registry entry exists. A suggestion for precedence is
harder in connection with the `default' registry entry I mentioned above.
Any suggestions? Note, however, that the proper mode should also cover
standard input/output, when these streams are not directed to the console.
Sergey, has solved that in recent coolview versions
(I believe by checking the mount entry for /, for a binary setting--is it so?).
I definitely wouldn't want to see this aspect broken again. Things like
`gunzip .. | tar xf -' should work, regardless of the shell used for invocation.

>     Cons:
> 
> 	a)  May slow down process startup slightly (I haven't noticed this
> 	    in simple tests, though).
> 
There are so many other major sources of slowness, that I don't think this
one will make a significant difference.

> 	b)  Contributes to creeping featuritis.
> 
Something that we should try to keep to a minimum. I definitely wouldn't want
to see twenty possible options being settable, a year from now.
Discipline and discretion must be applied when using any powerful tool or
mechanism. In particular, the scheme proposed should NOT be used for
`sweeping under the rug' problems that should be fixed by updating the source
code of individual programs.

> 	c)  The BINMODE option is nice, but may delay true port of a
> 	    product in favor of a "SET CYGWIN_BINMODE" band-aid.
> 
For programs that their natural mode of operation is `binary' (cmp is an
obvious example), I believe the program's code should enforce it
explicitly; registry or environment settings are, in my opinion,
just a temporary patch. (I admit that there is a `grey zone' of programs
that could benefit from both file modes.)

> The available options are:
> 
> 	[no]binmode		- Set default open mode
> 	[no]title		- Display program names on the console
> 				  title bar
> 	[no]glob		- [Do not] interpret wild cards on commands
> 				  run from CMD.
I hope this will affect only invocations from within CMD or COMMAND.COM,
or any (and all) non-Unix shell. 

While at it, let me note that I would like to see a setting like dosglob,
which, when activated, would perform dos-like globbing (the sort of thing
you get when you link with an appropriate module in Microsoft compilers).
Again this should apply only in case the program is invoked from within
CMD/COMMAND.COM. This would make globbing more transparent from within Microsoft
shells (whose design is responsible for this mess in the first place), when
using a mixture of cygwin and non-cygwin tools.

> 	[no]strip_title		- [Do not] strip the path component of files
> 				  names displayed in the title bar
> 	[no]tty			- Attach a UNIX-style tty to the program
> 
> All of the above are available as normal CYGWIN_* environment variables:
> 
> 	CYGWIN_BINMODE, CYGWIN_NOBINMODE
> 	CYGWIN_TITLE, CYGWIN_NOTITLE
> 	etc.
> 
> These settings are similar to those found in Sergey's recent coolview
> release except that it is possible to say CYGWIN_NOTITLE as well as
> CYGWIN_TITLE.
> 

What happens if one has set both CYGWIN_TITLE and CYGWIN_NOTITLE?

> Which leads into another source of discussion.  I would prefer something
> like this for setting these options:
> 
> 	set CYGWIN32=binmode notitle tty
> 
> rather than:
> 
> 	set CYGWIN_BINMODE=1
> 	set CYGWIN_TTY=1
> 	set CYGWIN_NOTITLE=1
> 
> My current patch allows both uses but it would probably better to stick
> with one.
> 

I definitely prefer the CYGWIN32 approach.

> 2) CYGWIN32
> 
>     Pros:
> 
> 	a)  Minimizes environment variable name space pollution.
> 
> 	b)  Mirrors proposed registry options syntax.
> 
> 	c)  More intuitive?
> 
I agree with all

>     Cons:
> 
> 	a)  May be harder to test for in shell scripts.
> 
Still easy (and possible using built-in sh features), for any competent
shell programmer. An example script may be provided for helping users with
little Unix experience.

> 	b)  Less intuitive?

Not for me. It depends on the individual user's frame of mind. The resemblance
of registry and environment syntax is, in my opinion, enough justification.

Best Regards,

Kimon Kontovasilis.
------------------------
Dr. Kimon Kontovasilis,
National Center for Scientific Research,
Institute for Informatics & Telecommunications,
e-mail: [email-masked]
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".