This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Feedback needed on proposed cygwin feature


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]