This is the mail archive of the cygwin-developers 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]
Other format: [Raw text]

Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty


Corinna Vinschen wrote:
> On May 12 12:58, Charles Wilson wrote:
>> Sortof. Part of 000-cygwin-post-install.sh's JOB is to create that file
>> -- and it did so.  So the file exists for the rest of the postinstall
>> scripts. However, I wonder if there is a caching problem or something --
>> sure, it was created, but doesn't get used until the next time
>> cygwin1.dll is loaded into memory?>
>
> Right, but since all postinstall scripts run sequentially with no other
> cygwin process in memory, the initialization including reading fstab
> files is done for each bash call.

Ack.

>> That's right: NO shebang line.
>
> Nevertheless it has been run as script.  That's quite interesting
> because...
> 
>> 2009/05/11 14:56:28 running: C:\cygwin-1.7\bin\bash.exe -c
>> /etc/postinstall/terminfo.sh
>
> ...isn't that wrong?  bash is called from setup with a *script* as
> parameter, not with a *command*.  Shouldn't that be `bash foo.sh',
> rather than `bash -c foo.sh'?  

Hmm -- I don't think so.  What if foo.sh is actually foo.tcsh, or foo.pl
or foo.py?

#! /bin/tcsh
<cmds>

In that case, you'd want to treat "foo.tcsh" as if it were an
application (e.g. a command), and let the kernel figure out how to
launch it -- by inspecting the shebang line.

> And I'm really wondering if your .dotfiles script isn't the problem
> here.  Why is it read anyway?  Do you have a $HOME in your Windows
> environment?  After all, $HOMEDRIVE$HOMEDIR isn't utilized anymore
> to generate a $HOME in Cygwin.

Actually, our IT guys have changed how they image new computers. As it
happens, "they" now set up the default windows profiles such that the
windows environment contains %HOME% = H:\ (and they explicitly mount our
remote home directories to H:).  I had assumed that the "old" procedures
were used: that is, no explicit %HOME% var, so if cygwin found my H:\
drive, it had to be a $HOMEDRIVE$HOMEDIR issue.  But it wasn't; it was
actually just a $HOME issue.  But even so -- IMO the postinstall scripts
shouldn't read ~/.dotfiles.  However...

> Shouldn't setup better use the --norc option?

Yes.  Here's a transcript of a session in a cmd box (which -- I think --
should emulate the environment in which setup.exe invokes the
postinstall scripts):

H:\>PATH=C:\cygwin-1.7\bin;%PATH%

H:\>type foo.sh
#!/bin/bash
echo I am $0
echo PATH is $PATH

H:\>type foo.pl
#!/bin/perl
use strict;
print STDOUT "I am foo.pl\n";

H:\>C:\cygwin-1.7\bin\bash.exe -c ./foo.sh
I am ./foo.sh
PATH is
/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/program
files/rational/clearcase/bin:/cygdrive/c/program
files/rational/common:/cygdrive/c/Program
Files/MATLAB/R2007A/bin:/cygdrive/c/Program
Files/MATLAB/R2007A/bin/win32

[[[ so, the above command line gives the behavior we want. AND it looks
exactly like what setup.exe SAYS that it is doing. ]]]

H:\>C:\cygwin-1.7\bin\bash.exe -l -c ./foo.sh
/cygdrive/h/.bash_profile
/cygdrive/h/.bashrc
I am ./foo.sh
PATH is
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/program
files/rational/clearcase/bin:/cygdrive/c/program
files/rational/common:/cygdrive/c/Program
Files/MATLAB/R2007A/bin:/cygdrive/c/Program
Files/MATLAB/R2007A/bin/win32:/usr/lib/lapack

[[[ as expected, the login shell does both .bash_profile and .bashrc, at
least the way my .dotfiles are set up ]]]

H:\>C:\cygwin-1.7\bin\bash.exe -i -c ./foo.sh
/cygdrive/h/.bashrc
I am ./foo.sh
PATH is
/usr/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/system32/wbem:/cygdrive/c/program
files/rational/clearcase/bin:/cygdrive/c/program
files/rational/common:/cygdrive/c/Program
Files/MATLAB/R2007A/bin:/cygdrive/c/Program
Files/MATLAB/R2007A/bin/win32

[[[ Ah-HA! This looks like what setup.exe is actually doing. So, for
whatever reason, the bash session is considered interactive. That's odd,
and appears to contradict the man page fragment below. ]]]

H:\>C:\cygwin-1.7\bin\bash.exe -i -c ./foo.pl
/cygdrive/h/.bashrc
I am ./foo.pl

[[[ so, this is what happens when an interactive bash session runs the
foo.pl command ]]]

H:\>C:\cygwin-1.7\bin\bash.exe -i ./foo.pl
/cygdrive/h/.bashrc
./foo.pl: line 2: use: command not found
Unable to initialize device PRN

[[[ and, without -c, it breaks.  So, we definitely need -c. ]]]

H:\>C:\cygwin-1.7\bin\bash.exe --norc -i -c ./foo.pl
I am ./foo.pl

[[[ now THIS is right. ]]]

So, it seems to me that we either need to (a) figure out why the initial
bash session invoked by setup.exe is "interactive" and make it NOT
interactive, or (b) punt on that, and explicitly pass --norc.  I vote
for (b).

> Why does bash read an rc file at all?  The man page claims that only
> interactive bash shells read profiles and non-interactive bashes only
> read an rc script if $BASH_ENV is set.

it seems to me that the problem is actually caused by the primary bash
invocation, not the shebang one. OTOH, the man page also says:

"An interactive shell is one started without non-option arguments,
 unless `-s' is specified, without specifiying the `-c' option, and
 whose input and error output are both connected to terminals (as
 determined by `isatty(3)'), or one started with the `-i' option."

It's oddly worded, but seems to say that "-c" == non-interactive, and
therefore should not be reading my dotfiles.  However -- as demonstrated
above, the initial bash environment is definitely in interactive mode.

Another interesting tidbit:

"If Bash is started with the effective user (group) id not equal to the
 real user (group) id, and the `-p' option is not supplied, no startup
 files are read, shell functions are not inherited from the environment,
 the `SHELLOPTS' variable, if it appears in the environment, is ignored,
 and the effective user id is set to the real user id."

> And the postinstall scripts should be self-sufficient anyway.

Ack.

> I suggest to remove the script from your homedir and retry.  This looks
> suspicious and, as I said, I didn't have that problem.

Well, ok. But, if I have valid ~/.dotfiles, AND %HOME% is set -- as
might be the case if I had an existing interix or msys installation -- I
still should be able to install cygwin without (a) errors, or (b) being
required to "prepare" my computer by removing those things.  Now, if my
~/.dotfiles do interix-specific things and I haven't been careful to
guard them using case `uname` clauses, then when I try to *use* cygwin
it might break, and that's my own fault.  But the *installation* ought
not to fail, as mine did.

Going on your "postinstall scripts should be self-sufficient anyway", I
think at least we should modify setup to do

C:\cygwin-1.7\bin\bash.exe --norc -c <cmd>

and maybe even forcibly add --noprofile, as well.

--
Chuck


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