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

2 Dec 1997 10:58:46 -0800
Message-ID: <[email-masked]>
To: [email-masked]
Cc: [email-masked]

>> 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.)

Actually, I have implemented a registry default (should have mentioned it)
but I'm not talking about dispensing with environment variables.  They
are still very useful in certain situations.  Environment variables take
precedence over registry options.

>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.)

I don't see any way around this other than to either use NT extended
attributes (which don't work on Windows 95) or to modify the binary header
which I don't have the expertise to do.

Or, continue to use 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.

Forgoing the the path part of the program name is a possibility.  I don't
like it because it makes debugging a little program harder.

>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.

I use GetModuleFilename to find the name of the running program.  This
should always return a consistent name.

>> 	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.

This is tricky, I agree.  For the way that it is currently implemented,
the 'binmode' setting merely changes the program's default setting for
opens which do not specify binmode or textmode.  That means that if you
specifically set O_TEXTMODE (or whatever) in an open it will override
the binmode setting.  If you have a disk mounted as textmode but have
`binmode' set, then a file opened on that disk will be opened as textmode.

>>     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.

Yeah, but I don't really want to contribute to slowing down cygwin.  Every
nifty feature added to cygwin may have a price.

>> 	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. 

Yup.

>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.

I'm not sure how this would work.  Do you mean that you'd actually like
to have things like c:\bin\*foo.exe be equivalent to c:\bin\*.exe and you'd
like to disallow c:\*\foo.exe?

>> 	[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?

Currently, CYGWIN_TITLE would win because the Win32 environment is maintained
in sorted order and CYGWIN_TITLE occurs after CYGWIN_NOTITLE.

If this is an issue, I could disable the CYGWIN_NO* environment variables.

Thanks very much for the feedback.
--
http://www.bbc.com/	[email-masked]			"Strange how unreal
VMS=>UNIX Solutions	Boston Business Computing	 the real can be."
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".