This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin-developers at cygwin dot com
- Date: Tue, 12 May 2009 22:10:04 +0200
- Subject: Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty
- References: <1242156396.3005.1315107915@webmail.messagingengine.com>
- Reply-to: cygwin-developers at cygwin dot com
[ Eric, do you, by any chance, follow this discussion? There's
a weird effect with bash thinking it has been started interactively
from setup. ]
On May 12 15:26, Charles Wilson wrote:
> Corinna Vinschen wrote:
> > On May 12 12:58, Charles Wilson wrote:
> >> 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?
Isn't supposed to work. setup allows .sh or .bat scripts and starts bash
or cmd.
> #! /bin/tcsh
> <cmds>
No, please. I'm tcsh maintainer but I don't want to see a postinstall
script doing *that*. Postinstall scripts shoudn't use any tool which
isn't part of the Base category anyway. Or isn't part of its own
requirements.
> > 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):
> [...]
> 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.
> > 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.
This would be a question for the bash maintainer... Eric?
> > 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.
I agree. It would be helpful if you could debug this in some way, being
the guy who can reproduce this...
> C:\cygwin-1.7\bin\bash.exe --norc -c <cmd>
>
> and maybe even forcibly add --noprofile, as well.
I'll give this a whirl.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat