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


According to Corinna Vinschen on 5/12/2009 2:10 PM:
> 
> [ Eric, do you, by any chance, follow this discussion?   There's
>   a weird effect with bash thinking it has been started interactively
>   from setup. ]

Yes, I've been following it, but I'm still mired in a backlog of emails
since I had limited access last week.  And since gmane mirrors cygwin, but
not cygwin-developers, I can't reply as easily.

>> Hmm -- I don't think so.  What if foo.sh is actually foo.tcsh, or foo.pl
>> or foo.py?
> 
> Isn't supposed to work.  setup allows .sh or .bat scripts and starts bash
> or cmd.

Actually, I see no reason why a different language script shouldn't work,
as long as...

> Postinstall scripts shoudn't use any tool which
> isn't part of the Base category anyway.  Or isn't part of its own
> requirements.

... this part is true.

>> 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).
> 
> I guess option (b) is inevitable.

Certainly the easiest - a single patch to setup.exe.  And we've already
done it in the past (we used to invoke [a]sh, but switched to invoking
bash as part of reducing the role of ash).  Another alternative would be
to ensure that stdin is redirected from NUL (or /dev/null, but this is
setup.exe we're talking about).

>> 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.
> 
> This would be a question for the bash maintainer...  Eric?

POSIX only states:

If the -i option is present, or if there are no operands and the shell's
standard input and standard error are attached to a terminal, the shell is
considered to be interactive.

(http://www.opengroup.org/onlinepubs/9699919799/utilities/sh.html)

In other words, if stdin and stderr are both ttys, then it seems like
posix requires both forms

sh script
sh -c 'executable-or-script'

to be interactive.

Whether bash (in bash mode, as opposed to when it is in posix mode because
it was invoked with the name 'sh') slightly tweaks the rules is something
I don't know off the top of my head, but for now let's assume that bash
had no reason to behave differently than the posix rules for sh, even
though the bash man page is harder to read than the posix rule.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net


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