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

Corinna Vinschen
Tue May 12 20:10:00 GMT 2009

[ 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/
> >
> > ...isn't that wrong?  bash is called from setup with a *script* as
> > parameter, not with a *command*.  Shouldn't that be `bash',
> > rather than `bash -c'?  
> Hmm -- I don't think so.  What if is actually foo.tcsh, or
> or

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

> > 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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list