Bug#288616: use of ">" in tetex postinst errors for sites using bash noclobber
"George Georgalis" <george@galis.org> wrote:
> On Mon, Jan 10, 2005 at 02:31:54PM +0100, Frank K?ster wrote:
>>"George Georgalis" <george@galis.org> wrote:
>>
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=275140
>>>
>>> I don't agree with all the points in message dated.
>>> Date: Sat, 9 Oct 2004 20:39:17 -0500
>>>
>>> eg debian doesn't set BASH_ENV by default, and I don't use it, which
>>> kinda breaks most of what he's saying, and sidetracked the issue.
>>
>>Why do you think that? Things usually work exactly because Debian, by
>>default, does no mixing up of the different initialisation files:
>>Because BASH_ENV is not set by default, and because it does not by
>>default source any of the initialisation files from any other, the
>>invocation modes are clearly separated.
>>
>>If on your system scripts starting with "#!/bin/sh" or "#!/bin/bash"
>>have noclobber set, I think this must be because you have tweaked the
>>initialisation process inappropriately, ending up with
>>interactive-specific things set in noninteractive shells.
>
> I don't think what I wrote, abet over condensed, was interpreted
> correctly. Simply, his issue was BASH_ENV, I don't use it, but I still
> have a login shell for *.postinst.
Do you think that the postinst scripts are run with a login shell, or do
you believe it? If you believe it, please give us some
evidence. For example, put some echo command into ~/.bash_profile which
is read by every login shell (we're speaking about bash, aren't we?) and
show us that it is echoed when you do dpkg-reconfigure.
If it turns out that it does echo the message, we have to strace the
call and look which files are actuall read. If again it turns out that
it is not due to some misconfiguration on your system, but that dpkg
calls it as a login shell, this is a bug in dpkg.
> I did find an exported BASH_ENV (which I don't normally use) in
> ~root/.profile I did check before, but somehow I missed it.
So you mean this is the cause of the behavior you observed?
> There may be something else though, even with export BASH_ENV=$HOME/.bashrc
> in $HOME/.profile and "set -o noclobber" in $HOME/.bashrc, I get the
> following results:
>
> root@run:~/ # cat testclobber.sh
> #/bin/bash
> touch ~/testclobber.txt
> echo >~/testclobber.txt
> root@run:~/ # source testclobber.sh
> bash: /root/testclobber.txt: cannot overwrite existing file
> root@run:~/ # sh testclobber.sh
> root@run:~/ #
Try "bash testclobber.sh" instead.
> I think it illustrates the system only sets noclobber for login shells.
No, this just illustrates that you overlooked the following part from
bash(1):
,----
| If bash is invoked with the name sh, it tries to mimic the startup
| behavior of historical versions of sh as closely as possible, while
| conforming to the POSIX standard as well. [...] A non-interactive
| shell invoked with the name sh does not attempt to read any other
| startup files.
`----
Note that this does not affect the shebang line; i.e. this compatibility
mode is not used when you write #!/bin/sh in the first line of a script
(I must admit that I don't know why).
> It would seem the apt-get/dpkg process invokes tetex.postinst as a login
> shell, because of the noclobber error creating the temp file -- feel
> free to correct me on this and I'll go away.
I have no indication that it does invoke it as a login shell, except
that you report a problem with your noclobber setting. But it also seems
that you didn't completely understand the startup behavior of bash (I
also have to look it up always), so probably it *is* just a
misconfiguration?
> I'd appreciate >> vs > for writing to mktemp files on the next release.
You mean >|, or what?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: