Re: Feedback needed on proposed cygwin feature

Re: Feedback needed on proposed cygwin feature

[marcus]

Jason Zions <jazz@softway.com> wrote:
>It strikes me that the best place for per-binary attributed like this
>would be in the binary itself. I don't know how closely cygwin's exec()
>looks at the program being exec'd; if it looks at the program header,
>there should be a way to squirrel the attributes away there someplace.

If there isn't anyplace in the file header that can be used to store this
info away in that doesn't upset NT/W95, or if it is costly to open the object
file whenever a program starts execution, perhaps it would be possible to
provide some global variables in the crt0.o module for controlling various
attributes.  The tool to set the attributes would have to go through the
name list to find the variables, then find the section to modify.  Shouldn't
be too bad, and the performance of the attribute setting program isn't
critical anyway, but it would require that the file not be fully stripped.

On the other hand, perhaps a data section could be defined that contains an
array of attribute flags, or even space for ASCII attribute names.  This
section (perhaps .cygwin_attributes) could be initially provided by the crt0.o
file, then a pointer to it is passed to the DLL on process startup.

Using an array of flags allows easy allowance for significant expansion, but at the cost of having a fixed structure (i.e. the first flag corresponds to the
force-binary attribute, the second flag...) while the ASCII attribute name
requires a "big enough" fixed size buffer be pre-allocated to hold the list
of attributes, and what happens when an attribute name is not recognized by
the DLL?  Of course, perhaps the attribute setting program could change the
section size, etc....

cgf replies to Jason:
> Also, in actuality, the binary does not know that it has been invoked via
> a symbolic link since this is a cygwin affectation.  If you have two
> files hard linked together you might actually *want* to have separate
> settings for them.

You might want separate settings in some cases, but you might also get very
confused by separate settings as well.  If this is supposed to be "Unix-like",
then it would be least surprising to attach the attribute to the file instead
of the name.

Other issues with using name:

The full path name must be unambiguously stored with the attribute and expanded
for execution.  Otherwise, some peculiar things may not work correctly, such
as invoking the program as "../bin/program", using a symbolic link to a
directory "symlinktobin/program", etc.  If the attributes are not consistently
found whenever a program is run, the program will have inconsistent behaviour.

If attributes are set for a program, then the program is moved to another
location or given another name, it looses the attributes.  Furthermore, if
a new program is created (perhaps months later) with the same name and
location, it will mysteriously gain the attributes.  These problems do apply
to symbolic links currently, so they aren't new, but they can be confusing
particularly since they may have subtle effects on the execution of the program
instead of a hard failure to follow a link.

marcus hall
Lucent Technologies
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Tomas Fasth]

Modifying the exe file "on-the-fly" for environmental settings is not to
recommend. Two of the reasons I can think of is:

* Security considerations in a multiuser / multiprocess environment.
* Will cause problem in environments with active virus protection.

Tomas
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 34856623.C5226DBC@twinspot.net >,
Tomas Fasth  <tomas.fasth@twinspot.net> wrote:
>Modifying the exe file "on-the-fly" for environmental settings is not to
>recommend. Two of the reasons I can think of is:
>
>* Security considerations in a multiuser / multiprocess environment.

What security considerations are there that are not also present with
any other scheme, whether it is using extended attributes or setting options
in the registry?  You would have to have the right privileges to change
the binary.

>* Will cause problem in environments with active virus protection.

How does a virus detection program detect the difference between installing
a new version of bash or changing a byte in the existing file?
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Tomas Fasth]

Chris Faylor wrote:

> What security considerations are there that are not also present with
> any other scheme, whether it is using extended attributes or setting options
> in the registry?  You would have to have the right privileges to change
> the binary.

The binary is normally a single entity, shared among users. Configuring
a certain  behavior at compile time is just fine, having it modified
after installment is not. It will simply introduce all kinds of
nightmares.

If a user wants to change the behavior of a certain binary, it has to be
done within that particular user's environment only. Otherwise, you will
end up with a situation where no-one can trust current settings and
being forced to check/reset the settings at each and every point of use.

If I remember right, the registry allow user specific entries. Also,
it's nothing new in the Unix environment to have configuration files for
binaries stored within the file system space controlled by current user.
We just have to figure out a viable structure to store such information
into.

> How does a virus detection program detect the difference between installing
> a new version of bash or changing a byte in the existing file?

It does not. At both occations the virus tripwire will be sprung.

But a binary installation is normally a system level activity, or at
least done with an intention to share the binary among some or all of
the users on that system.

A change of a binary's runtime behavior should not require a change to
the binary itself. I'm quite surprised that this option came up in the
discussion in the first place. Everybody having worked in the Unix
environment should realize the obvious security breach such solution
would introduce. NT is certainly not an exception.

I strongly recommend to leave the binary alone.

Tomas
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 34870542.A0933226@twinspot.net >,
Tomas Fasth  <tomas.fasth@twinspot.net> wrote:
>Chris Faylor wrote:
>
>> What security considerations are there that are not also present with
>> any other scheme, whether it is using extended attributes or setting options
>> in the registry?  You would have to have the right privileges to change
>> the binary.
>
>The binary is normally a single entity, shared among users. Configuring
>a certain  behavior at compile time is just fine, having it modified
>after installment is not. It will simply introduce all kinds of
>nightmares.
>
>If a user wants to change the behavior of a certain binary, it has to be
>done within that particular user's environment only. Otherwise, you will
>end up with a situation where no-one can trust current settings and
>being forced to check/reset the settings at each and every point of use.
>
>If I remember right, the registry allow user specific entries. Also,
>it's nothing new in the Unix environment to have configuration files for
>binaries stored within the file system space controlled by current user.
>We just have to figure out a viable structure to store such information
>into.
>
>> How does a virus detection program detect the difference between installing
>> a new version of bash or changing a byte in the existing file?
>
>It does not. At both occations the virus tripwire will be sprung.

Can you point me to some specific virus software that will complain given
the above scenario?

>But a binary installation is normally a system level activity, or at
>least done with an intention to share the binary among some or all of
>the users on that system.
>
>A change of a binary's runtime behavior should not require a change to
>the binary itself. I'm quite surprised that this option came up in the
>discussion in the first place. Everybody having worked in the Unix
>environment should realize the obvious security breach such solution
>would introduce. NT is certainly not an exception.

I guess I need more explanation about why it is "obvious" that modifying
the binary results in a security breach.  A user either has the right
to modify the binary or they don't.  If they don't, it is not a security
problem.  If they do then they can replace 'ls' with 'rm' if they want to.
They can also edit the binary with 'vi'.  So what?

Your point about individual users not being able to set their own per-binary
defaults is a good one, though.  So, I guess that means that we're back
to the registry, with all its attendent quirks.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 199712021608.JAA04416@chorus.dr.lucent.com >,
 <marcus@bighorn.dr.lucent.com> wrote:
>Jason Zions <jazz@softway.com> wrote:
>>It strikes me that the best place for per-binary attributed like this
>>would be in the binary itself. I don't know how closely cygwin's exec()
>>looks at the program being exec'd; if it looks at the program header,
>>there should be a way to squirrel the attributes away there someplace.
>
>If there isn't anyplace in the file header that can be used to store this
>info away in that doesn't upset NT/W95, or if it is costly to open the object
>file whenever a program starts execution, perhaps it would be possible to
>provide some global variables in the crt0.o module for controlling various
>attributes.  The tool to set the attributes would have to go through the
>name list to find the variables, then find the section to modify.  Shouldn't
>be too bad, and the performance of the attribute setting program isn't
>critical anyway, but it would require that the file not be fully stripped.

Hmm.  You're right.  It should be possible to store an identifying string
in the binary for the options setting program to look for and then modify
the settings in the .exe.

I feel like I've been arguing out of both sides of my mouth, but the
only problem I see with this is for the people who want to set up various
symbolic links to the file and then set different registry options for
each link.  If we modify the binary, then this wouldn't work.

Thanks for this suggestion.

>Other issues with using name:
>
>The full path name must be unambiguously stored with the attribute and expanded
>for execution.  Otherwise, some peculiar things may not work correctly, such
>as invoking the program as "../bin/program", using a symbolic link to a
>directory "symlinktobin/program", etc.  If the attributes are not consistently
>found whenever a program is run, the program will have inconsistent behaviour.

This shouldn't be an issue since, in the current scheme, only the MS-DOS
path spec retrieved from GetModuleFilename is used.

>If attributes are set for a program, then the program is moved to
>another location or given another name, it looses the attributes.
>Furthermore, if a new program is created (perhaps months later) with
>the same name and location, it will mysteriously gain the attributes.
>These problems do apply to symbolic links currently, so they aren't
>new, but they can be confusing particularly since they may have subtle
>effects on the execution of the program instead of a hard failure to
>follow a link.

Well put.  You're right.  I hate to set something up like this which
requires that you "remember" to remove the registry option when you
remove the file.  Of course, you could have cygwin recognize when a
program has been deleted and delete it from the registry, I guess.

I think I like the binary modification idea better, though.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

>>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
>
>I nearly sent a rave about how pointless this is because even more
>functionality can already be achieved with environment variables alone
>(at the cost of extra short-lived bash processes to tailor the environment).

So use environment variables then.  I'm not advocating getting rid of
environment variables.  I don't see how reading of options from the
registry can remove functionality.

What the registry can do, that your bash scripts only approach can't, is
allow things like setting up inetd to default to CYGWIN_TTY.  Running
inetd from a shell script that sets CYGWIN_TTY=1 is not easy.  The other
alternative is to set the global environment variable CYGWIN_TTY to 1
and then unset it on a per-session basis.  Yup.  That's pretty flexible.

On top of this, you have to add the not-inconsiderable speed improvement
from reading the registry versus firing up bash (or ash or whatever) to
start up a shell script which sets an environment variable and runs another
program.

>My most serious concern was the loss of functionality:
>
>    Your proposition only seems to cater for per-application configuration,
>    not per-*process* configuration.
>
>Someone else made this point and referred to multiple copies of binaries
>which you thought was a bad thing. But your proposition would *require*
>multiple binaries if users wanted per-process configuration!

Use environment variables, then.  You haven't lost anything.

>Without this extension, the proposition only speeds up per-application
>configuration and users would then have to fiddle the registry *and* the
>environment to achieve per-process configuration.

Don't fiddle with the registry.  Use environment variables.

>With this extension, it speeds up per-process configuration as well.

I'm not so sure, since symbolic links mean nothing to the normal command
shell.  So, you could have:

-rwxr-xr-x   1 cgf      everyone  1716020 Oct 28 09:02 /bin/bash.exe
lrwxr-xr-x   1 cgf      everyone       19 Dec 03 09:40 bashbin.exe -> bash.exe

and have bash default to "text" mode opens and bashbin default to "binmode"
opens.

But running bashbin would never work from the command shell:

C:\bin>bashbin
The name specified is not recognized as an
internal or external command, operable program or batch file.

Of course, this would work:

C:\>bash
$ CYGWIN32=nobinmode bash
$

Personally, I don't think that that is extremely odious.

>So my suggestion is not to use dos-style file paths in the registry,
>but rather cygwin-style file paths (thus including binaries, scripts
>and symbolic links).  This shouldn't be a problem since it only applies
>to cygwin programs anyway(?).

When you ask a process what name it was invoked by, it returns a MS-DOS
style path name.  That's what I'm currently using.  It is pretty foolproof.

I don't remember saying that the registry stuff wouldn't work with
scripts but neither scripts nor symbolic links are impossible to do, and
if the consensus is that it is crucial, then I'll look into implementing
it.

My feeling from reading this newsgroup is that 99% of the problems that
occur are when a user ports the nifty UNIX XYZ program to cygwin32.
Everything compiles ok, but when the user tries to run the program it
seems to screw up reading data files.  In this case, setting a 'binmode'
registry option for the program would solve the problem.

I haven't seen much traffic on the list from people complaining that
they have to set up shell scripts to turn off 'TITLE' or 'TTY' for a
program some of the time but leave them on for others.  I also don't see
why a program would *want* to sometimes default to opening files in
O_BINARY and sometimes default to O_TEXT.  Of course, since
CYGWIN_BINMODE is not available yet perhaps this is a requirement that
is waiting in the wings.

Perhaps someone could, in a non-raving manner, enlighten me with some
real-world examples.

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Feedback needed on proposed cygwin feature

[Michael Anthon]

On Thursday, 4 December 1997 12:31, cgf@bbc.com [SMTP:cgf@bbc.com]
wrote:
> In article < 34856623.C5226DBC@twinspot.net >,
> Tomas Fasth  <tomas.fasth@twinspot.net> wrote:
> >Modifying the exe file "on-the-fly" for environmental settings is not
to
> >recommend. Two of the reasons I can think of is:
> >
> >* Security considerations in a multiuser / multiprocess environment.
> 
> What security considerations are there that are not also present with
> any other scheme, whether it is using extended attributes or setting
options
> in the registry?  You would have to have the right privileges to
change
> the binary.

Modification of binary files in a multi-user environment is not a good
thing.  The registry is there, you may as well use it.  Something I have
not yet seen mentioned is the fact that each user can have a separate
profile in the registry, making it easy for each user to have different
settings.  Modifying the binary might get just a little frustrating if
someone else keeps changing it to the way THEY like things (unless you
want to fill your hdd with multiple copies of executables)
Also, for a user to be able to modify a binary, they would need write
access to that binary.  I suspect this would cause nightmares for sys
admins, not to mention the possibility of adding back doors directly
into the binaries themselves.  I bet a normal user can't modify any of
the shell binaries in a standard Unix setup.

> 
> >* Will cause problem in environments with active virus protection.
> 
> How does a virus detection program detect the difference between
installing
> a new version of bash or changing a byte in the existing file?

SOME virus protection schemes are now including a mechansim whereby any
changes to an executable file will raise a warning.  Norman Anitvirus is
one in particular that I have used that does this.  It's a bit of a pain
if you forget to disable that feature before installing any new
software.  If that installation tries to upgrade, for example, a dll
file, as most of them seem to do these days, the Virus detection kicks
in and gives you a warning.

The same thing would apply to modification of the executables as
suggested here.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 3120D53DC9D5D011A59A00C0F016383303A323@server1 >,
Michael Anthon  <anthonm@tams.com.au> wrote:
>On Thursday, 4 December 1997 12:31, cgf@bbc.com [SMTP:cgf@bbc.com]
>wrote:
>> In article < 34856623.C5226DBC@twinspot.net >,
>> Tomas Fasth  <tomas.fasth@twinspot.net> wrote:
>> >Modifying the exe file "on-the-fly" for environmental settings is not
>to
>> >recommend. Two of the reasons I can think of is:
>> >
>> >* Security considerations in a multiuser / multiprocess environment.
>> 
>> What security considerations are there that are not also present with
>> any other scheme, whether it is using extended attributes or setting
>options
>> in the registry?  You would have to have the right privileges to
>change
>> the binary.
>
>Modification of binary files in a multi-user environment is not a good
>thing.  The registry is there, you may as well use it.  Something I have
>not yet seen mentioned is the fact that each user can have a separate
>profile in the registry, making it easy for each user to have different
>settings.  Modifying the binary might get just a little frustrating if
>someone else keeps changing it to the way THEY like things (unless you
>want to fill your hdd with multiple copies of executables)
>Also, for a user to be able to modify a binary, they would need write
>access to that binary.  I suspect this would cause nightmares for sys
>admins, not to mention the possibility of adding back doors directly
>into the binaries themselves.  I bet a normal user can't modify any of
>the shell binaries in a standard Unix setup.

No, you're right.  A normal user would use environment variables, which
are still available.

I had envisioned the use of the registry as a way to set defaults for
specific programs on a system, not as a way for each user to modify
their needs for a specific program.  It is a subtle difference.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Earnie Boyd]

>From: Chris Faylor <cgf@bbc.com>
>Date: Mon, 1 Dec 1997 17:46:58 -0500 (EST)
>To: jazz@softway.com
>Subject: Re: Feedback needed on proposed cygwin feature
>Cc: gnu-win32@cygnus.com
>
>>> Extended attributes are not an option for Windows 95, however.
>>
>>Didn't Sergey's Coolview extensions provide a mechanism for storing
>>extended attributes on FAT filesystems and under Win95? Or am I
>>misremembering things?
>
>Just under Windows NT, I think.
>
>I do remember that people using FAT on Windows NT complained because
>cygwin was creating a large file to hold the extended attributes, also.
>That may be another mark against using them.

Yes, the file grew to be about 150M before I found out what was eating 
up the disk space.  I removed the coolview patches on my Windows NT but 
now use the latest coolview on my W95.  My WinNT has a FAT mount.

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[dahms]

Hi Fergus, you wrote:

: I don't see any good reason to hard-code the `32'.
: 
: Using `CYGWIN32' won't look very good on say the 64-bit NT Alpha port.

MS should have made the jump to >32bit at NT4, at a time several other
unices already were 64bit, and provide a real useful POSIX before forcing
all of us to NT, saving all this hassle!


Bye, Heribert (dahms@ifk20.mach.uni-karlsruhe.de)
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Theodore Jump]

>: Using `CYGWIN32' won't look very good on say the 64-bit NT Alpha port.

It's still banging against the "Win32" API even though it's running on
a 64-bit machine - so "CYGWIN32" is still accurate, IMHO.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

>> 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/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

>Chris Faylor wrote:
>> 
>> 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.
>> 
>> 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 can see a possible problem: the change is limited to the copy of the
>program in that directory.  If you use the above example, but have
>another copy of the program in a different directory, the changes will
>not carry over, which in some, but not all, eyes could be a bad thing,
>since you would have to have an entry for each instance of the program
>you want to run.  If, however, you just use the program name without the
>path, the changes would be global for all instances of that program,
>which is a little better in my opinion.

I'm not sure that I agree.  Actually, it could be made to check a default
location, the program without the path, and the program with the path but
that would certainly slow down program startup for, IMHO, minimal gain.

I'm also not sure what the gain would be in keeping multiple copies of a
program around.  If you have the same program sitting in multiple directories
it seems to me that you are a candidate for running CleanSweep.

>	But that just brings up another question: what about instances run from
>symlinks?

Symlinks are a cygwin construction.  The actual program being run is always
the program that they point to.  GetModuleFilename returns the actual
path name of the program and that is what I (currently) use.
--
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

>Jason Zions <jazz@softway.com> wrote:
>It strikes me that the best place for per-binary attributed like this
>would be in the binary itself. I don't know how closely cygwin's exec()
>looks at the program being exec'd; if it looks at the program header,
>there should be a way to squirrel the attributes away there someplace.
>
>Many "real Unix" systems do just this sort of thing; e.g. chatr in
>HP-UX, which is used to alter a.out attributes.
>
>Pro: 
>  a) attributes are *really* a part of the binary; symlinks and
>hardlinks all pointing to the same bits on the disk will behave the
>same, while name-based approaches may be inconsistent
>
>  b) makes it easier for attributes to work over network mounts (when
>filesystems can be mounted in different places)
>
>Con:
>  a) extracting the attributes from the binary may be slower
>
>  b) may be hard to find a "safe place" to stash the bits

Actually, Geoffrey had already mentioned this scenario in private email.
I should have mentioned it in my original message.

It is certainly doable using extended attributes on Windows NT.
Extended attributes are not an option for Windows 95, however.  I think
that it would end up being slightly slower than using the registry since
the registry options stand a better chance of being cached than a file's
attributes.

I agree that it probably would be possible to modify the binary header.
I don't have the expertise to do so, however.  If anyone else can volunteer
a way to store arbitrary data in PE binary I'll be happy to incorporate it.

Also, in actuality, the binary does not know that it has been invoked via
a symbolic link since this is a cygwin affectation.  If you have two
files hard linked together you might actually *want* to have separate
settings for them.

cgf
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Jason Zions]

> Extended attributes are not an option for Windows 95, however.

Didn't Sergey's Coolview extensions provide a mechanism for storing
extended attributes on FAT filesystems and under Win95? Or am I
misremembering things?

Jason
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

>> Extended attributes are not an option for Windows 95, however.
>
>Didn't Sergey's Coolview extensions provide a mechanism for storing
>extended attributes on FAT filesystems and under Win95? Or am I
>misremembering things?

Just under Windows NT, I think.

I do remember that people using FAT on Windows NT complained because
cygwin was creating a large file to hold the extended attributes, also.
That may be another mark against using them.
--
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

RE: Feedback needed on proposed cygwin feature

[JONCKHEERE]

                                     D0TNG (D0 AXP cluster) @FNAL,  1-DEC-1997
---------------------------------------------------------------------------
> From:	SMTP%"cgf@bbc.com"  1-DEC-1997 06:08:43.18
> To:	JONCKHEERE
> CC:	
> Subj:	Feedback needed on proposed cygwin feature
> 
> I have recently provided a patch to Cygnus to provide control of various
> environment variable settings on a program by program basis.

Is this patch generally available yet? If so where? If not when can we
expect to see it?
 
> 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.

From your discription it looks like *just* the sort of thing we need.
But probably needs some generalization.

We are porting a large body of code from Unix to NT, including the code
development system used on Unix (CVS and a home brewed set of scripts
and makefiles). It all works very well in the DOS command line window.
But we'd like to integrate it into the windows environment. The
biggest problem we face is that the various exes require different,
sometimes conflicting environment variable values.

At the moment we invoke each exe via a bash shell script which sets
the variables. But this is something of a kludge. It sounds like your
patch, or a generalization of it, might allow a much more elegant
solution to our problem. 
 
> 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.
> 
> 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.
> 	[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.

Can the list of variables be expanded by the user? I'd like to be able
to do things like setting PYTHONPATH (or just PATH) to an arbitrary
value depending on the exe, and the version of the exe, I'm running. 
 
> 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.
> 
> 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.
> 
> 	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.
> 
> 	c)  "Solves" the problem of programs, ported from UNIX, which need
> 	    to use `binmode' by default.
> 
>     Cons:
> 
> 	a)  May slow down process startup slightly (I haven't noticed this
> 	    in simple tests, though).
> 
> 	b)  Contributes to creeping featuritis.
> 
> 	c)  The BINMODE option is nice, but may delay true port of a
> 	    product in favor of a "SET CYGWIN_BINMODE" band-aid.
> 
> 2) CYGWIN32
> 
>     Pros:
> 
> 	a)  Minimizes environment variable name space pollution.
> 
> 	b)  Mirrors proposed registry options syntax.
> 
> 	c)  More intuitive?
> 
>     Cons:
> 
> 	a)  May be harder to test for in shell scripts.
> 
> 	b)  Less intuitive?
> 
> I'd appreciate any and all feedback on this.  Please send comments to the list
> in general.
> 
> Thanks.

Naively, the cygwin32 form seems most appealing. But that depends on
the expandability of the list and if the list can be different for
each exe.

Hope this helps, Alan

> -- 
> http://www.bbc.com/	cgf@bbc.com			"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
> "gnu-win32-request@cygnus.com" with one line of text: "help".
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 971201101031.2680056c@d0tng.fnal.gov >,
 <JONCKHEERE@d0tng.fnal.gov> wrote:
>                                     D0TNG (D0 AXP cluster) @FNAL,  1-DEC-1997
>---------------------------------------------------------------------------
>> From:	SMTP%"cgf@bbc.com"  1-DEC-1997 06:08:43.18
>> To:	JONCKHEERE
>> CC:	
>> Subj:	Feedback needed on proposed cygwin feature
>> 
>> I have recently provided a patch to Cygnus to provide control of various
>> environment variable settings on a program by program basis.
>
>Is this patch generally available yet? If so where? If not when can we
>expect to see it?

I submitted the patch for B19 but it was "rejected" due to the radical
nature of the change.  Geoffrey asked that I get feedback from the group
before he committed to adding it.
 
>> 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.
>> 
>> 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.
>> 	[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.
>
>Can the list of variables be expanded by the user? I'd like to be able
>to do things like setting PYTHONPATH (or just PATH) to an arbitrary
>value depending on the exe, and the version of the exe, I'm running. 

Currently the list of options is fixed.  If you want to add arbitrary
environment variables from the registry then possibly that would be
another mechanism entirely.  Maybe something like:

cygwin -e c:\usr\local\bin\python.exe PATH='/python/bin:/bin' LIB='/python/lib'

I think it's a good idea, though.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Earnie Boyd]

Sounds like a great idea.

>From: cgf@bbc.com (Chris Faylor)
>Subject: Feedback needed on proposed cygwin feature
>Date: Mon, 1 Dec 1997 04:12:00 GMT
>To: gnu-win32@cygnus.com
>Reply-To: cgf@bbc.com
>

[snip]

>
>Which leads into another source of discussion.  I would prefer 
something
>like this for setting these options:
>
>	set CYGWIN32=binmode notitle tty

Less environment clutter.  Nice idea.

>
>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.
>
>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.
>
>	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.
>
>	c)  "Solves" the problem of programs, ported from UNIX, which need
>	    to use `binmode' by default.
>

text=binary on by default would be a definite benefit.

>    Cons:
>
>	a)  May slow down process startup slightly (I haven't noticed this
>	    in simple tests, though).
>
>	b)  Contributes to creeping featuritis.
>
>	c)  The BINMODE option is nice, but may delay true port of a
>	    product in favor of a "SET CYGWIN_BINMODE" band-aid.

I see nothing wrong with "What ain't broke don't fix" attitudes.

>
>2) CYGWIN32
>
>    Pros:
>
>	a)  Minimizes environment variable name space pollution.
>

This one gets my vote!

>	b)  Mirrors proposed registry options syntax.
>
>	c)  More intuitive?

Less hassle.

>
>    Cons:
>
>	a)  May be harder to test for in shell scripts.
>

To aid in testing a switch or environment variable could be added to 
turn on debug mode to display the values of the registry variables on 
stderr.  Or, a standalone program to list and modify registry elements 
by a given key?

>	b)  Less intuitive?

Only for those that aren't intuitive.

>
>I'd appreciate any and all feedback on this.  Please send comments to 
the list
>in general.
>
>Thanks.
>-- 
> http://www.bbc.com/	cgf@bbc.com			"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
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>


-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Feedback needed on proposed cygwin feature

[Chris Faylor]

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.

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.

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

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.

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.

	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.

	c)  "Solves" the problem of programs, ported from UNIX, which need
	    to use `binmode' by default.

    Cons:

	a)  May slow down process startup slightly (I haven't noticed this
	    in simple tests, though).

	b)  Contributes to creeping featuritis.

	c)  The BINMODE option is nice, but may delay true port of a
	    product in favor of a "SET CYGWIN_BINMODE" band-aid.

2) CYGWIN32

    Pros:

	a)  Minimizes environment variable name space pollution.

	b)  Mirrors proposed registry options syntax.

	c)  More intuitive?

    Cons:

	a)  May be harder to test for in shell scripts.

	b)  Less intuitive?

I'd appreciate any and all feedback on this.  Please send comments to the list
in general.

Thanks.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Norm Peterson]

On Mon, 1 Dec 1997, Chris Faylor wrote:

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

How about adding one more entry for the root dir?  This would help with
the chroot() problems.  If the registry key (or env variable, or whatever)
is set, use it's value as the root dir.  Otherwise use the global mount as
usual.



-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Jason Zions]

It strikes me that the best place for per-binary attributed like this
would be in the binary itself. I don't know how closely cygwin's exec()
looks at the program being exec'd; if it looks at the program header,
there should be a way to squirrel the attributes away there someplace.

Many "real Unix" systems do just this sort of thing; e.g. chatr in
HP-UX, which is used to alter a.out attributes.

Pro: 
  a) attributes are *really* a part of the binary; symlinks and
hardlinks all pointing to the same bits on the disk will behave the
same, while name-based approaches may be inconsistent

  b) makes it easier for attributes to work over network mounts (when
filesystems can be mounted in different places)

Con:
  a) extracting the attributes from the binary may be slower

  b) may be hard to find a "safe place" to stash the bits

Jason
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Justin Smith]

Chris Faylor wrote:
> 
> 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.
> 
> 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 can see a possible problem: the change is limited to the copy of the
program in that directory.  If you use the above example, but have
another copy of the program in a different directory, the changes will
not carry over, which in some, but not all, eyes could be a bad thing,
since you would have to have an entry for each instance of the program
you want to run.  If, however, you just use the program name without the
path, the changes would be global for all instances of that program,
which is a little better in my opinion.

	But that just brings up another question: what about instances run from
symlinks?
-- 

Justin Smith,
Systems Engineer with the law office of
  Dewey, Cheetam and Howe.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Theodore Jump]

(First off, my apologies to Chris as he's going to get this text twice
as I forgot to send it to the list only.)

Reflexively (meaning that I haven't coded or ported anything or done
extensive enough work inside the cygwin environment to have a real
strong opinion) I would say that I vote for your contribution be added
in to the "next" official release and I vote for the options to be
done in this way:

1. "cygwin-wide" Defaults are stored in the registry, and should be
   stored in the HKEY_LOCAL_MACHINE or HKEY_CURRENT_CONFIG hives to
   facilitate sharing among all "users" of the machine.

2. "program-specific" Defaults are stored in the registry underneath
   same hive as #1 above.  This would be analagous to the "App Paths"
   registry keys that are found in:

	HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/App Paths/

   Which specify modified paths to use for specific applications,
   if they need something other than the default system-wide path.

3. The environment variable CYGWIN32 operate as Chris documented, and
   if present overrides the defaults are stated in 1 and 2 above.

4. The 'cygwin' command operated as Chris documented, any options set
   there overriding anything set by the previous three options.

In all cases it could result in the existance of the CYGWIN32 env-var
as Chris documented so that applications that are cygwin-ized could
check that for safety and for runtime options.

It may be desireable to allow an option at the registry level to
disable usage of the 2nd two methods - for paranoia or security
reasons (e.g.: to prevent something launched from inetd or some other
daemon from altering a setting for a specific program as mandated by
the registry).

I do recognize that this is not the simplest of approches, however it
does facilitate both site-mandated configurations (particularly if
there is a registry-stored option for disabling 3 & 4) and user- or
program-specified additions/overrides.

By maintaining the support for the CYGWIN32 var it makes it trivial to
set/use that via scripts and batch files without modifying the system
registry (a not-quite-fast option) and without potentially huge
command lines.

Just my 2c.

-Ted
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Michael Hirmke]

Hi Chris,

[...]
>	cygwin -o 'c:\bin\bash.exe' binmode notitle

Where and how will these values get stored in the registry ?

>
[...]
>Which leads into another source of discussion.  I would prefer something
>like this for setting these options:
>
>	set CYGWIN32=binmode notitle tty

I'd like this way, too.

[...]
>Here are the pros and cons as we see them so far:
>
>1) Registry
[...]
>
>2) CYGWIN32

Uhm, perhaps I didn't get the point, but why is it necessary to list
pros and cons for this ? I'd like to see both possibilities in the next
version of cygwin and whoever wants can use one or both of them. If one
leaves the registry alone, only the env vars get used.
Perhaps it would be useful to have another env var available like
CYGWIN_REGISTRY=0|1 to indicate, whether one wants to use the registry
or not - this could speed up things and would allow to temporarily
disable the registry entries.

Bye.
Michael.
--
Michael Hirmke           | Telefon +49 (911) 557999
Georg-Strobel-Strasse 81 | FAX     +49 (911) 557664
90489 Nuernberg          | E-Mail  mailto:mh@mike.franken.de
                         | WWW     http://minimike.franken.de/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 6j3hs3X$pfB@mike.franken.de >,
Michael Hirmke <mh@mike.franken.de> wrote:
>Hi Chris,
>
>[...]
>>	cygwin -o 'c:\bin\bash.exe' binmode notitle
>
>Where and how will these values get stored in the registry ?
>
>>
>[...]
>>Which leads into another source of discussion.  I would prefer something
>>like this for setting these options:
>>
>>	set CYGWIN32=binmode notitle tty
>
>I'd like this way, too.
>
>[...]
>>Here are the pros and cons as we see them so far:
>>
>>1) Registry
>[...]
>>
>>2) CYGWIN32
>
>Uhm, perhaps I didn't get the point, but why is it necessary to list
>pros and cons for this ? I'd like to see both possibilities in the next
>version of cygwin and whoever wants can use one or both of them. If one
>leaves the registry alone, only the env vars get used.
>Perhaps it would be useful to have another env var available like
>CYGWIN_REGISTRY=0|1 to indicate, whether one wants to use the registry
>or not - this could speed up things and would allow to temporarily
>disable the registry entries.

I listed pros and cons because the features are not currently in any
version of cygwin.dll besides mine.  If the consensus is that the
Cons are more serious than the Pros then I'm sure that Geoffrey will
decide not to include the features in cygwin.dll.  And, I'd agree with
that decision.

Btw, since I don't seem to have made myself sufficiently clear, I was
not talking about removing environment variable support.  I was talking
about changing CYGWIN_* environment variables to CYGWIN32=*.  I don't
think there is any reason to keep both style of environment variables.
That would be needlessly confusing especially since it would never be
clear which had precedence.

CYGWIN_REGISTRY is an interesting idea.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Fergus Henderson]

cgf@bbc.com (Chris Faylor) writes:

>Btw, since I don't seem to have made myself sufficiently clear, I was
>not talking about removing environment variable support.  I was talking
>about changing CYGWIN_* environment variables to CYGWIN32=*.

I don't see any good reason to hard-code the `32'.

Using `CYGWIN32' won't look very good on say the 64-bit NT Alpha port.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Chris Faylor]

In article < 199712021741.EAA13772@mundook.cs.mu.OZ.AU >,
Fergus Henderson  <fjh@cs.mu.OZ.AU> wrote:
>cgf@bbc.com (Chris Faylor) writes:
>
>>Btw, since I don't seem to have made myself sufficiently clear, I was
>>not talking about removing environment variable support.  I was talking
>>about changing CYGWIN_* environment variables to CYGWIN32=*.
>
>I don't see any good reason to hard-code the `32'.
>
>Using `CYGWIN32' won't look very good on say the 64-bit NT Alpha port.

Good point.  Hmm.  How about:

CYGWIN32ORGREATER

?  :-)

Only kidding.  Now that I think of it, I can't remember why I added the
32 to begin with.  Probably just to distinguish it from the CYGWIN_*
style variables a little more.
-- 
http://www.bbc.com/	cgf@bbc.com			"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
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Feedback needed on proposed cygwin feature

[Kimon Kontovasilis]

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: kimon@cyclades.nrcps.ariadne-t.gr
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".