Re: I am not even remotely sure whether this is a bug: redefining getenv/setenv/et al.
On 3/10/16 3:48 PM, Peter Seebach wrote: > And I have for some time had a very strange problem, which is that > "sometimes" unsetting LD_PRELOAD doesn't work. Well, it turns out that the > issue is that bash provides its own definitions of getenv/setenv/unsetenv, > and they don't automatically modify environ. > > It seems pretty obvious to me that there are Sound Technical Reasons for the > shell to wish to maintain an "environment" which is not actually stored in > environ, so that part makes sense. > Bash maintains a set of variables, some of which have the export attribute. Those become the environment for processes that bash execs. Plenty of libc functions use the getenv/setenv interface to modify their behavior. So far, so good. Users expect the changes they make to exported shell variables to be reflected in the bash behavior. TZ (tzset) and the LC_ variables (setlocale) are examples; I'm sure there are others I don't mention. Bash redefines getenv/setenv (where possible) to allow libc functions that use those interfaces to retrieve current values of the exported shell variables. Bash lazily updates environ when it needs to create the export environment for a new child process, and makes it point to the list of exported variables it passes to execve(). There is no need to create functions like bash_getenv and bash_setenv; bash already has its own internal interfaces to set variable values and attributes and to retrieve them. It's true that modifying the value of environ crosses into Posix undefined behavior. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Hard-wrapped commands are displayed incorrectly after READLINE_LINE is changed
On 3/11/16 6:10 AM, Lauri Ranta wrote: > Bash Version: 4.3 > Patch Level: 42 > Release Status: release > > With for example `bind -x '"\ea":READLINE_LINE='` and `PS1='$ '`, if the > width of a shell window is 20 characters so that the 30 character command > > $ aa > > > is displayed on two lines, after pressing `\ea`, the command is displayed as > > $ aa > $ > > if the point is on the second line or as > > $ > > > if the point is on the first line. Yes, bash redraws the current line and does not erase the rest of the previous line contents. This is an artifact of how bash clears the current line before running the command specified by `bind -x'. I'll take a look at fixing this, but probably not before bash-4.4. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash and sshd trap anomaly
On 3/10/16 10:07 AM, Olof Schonbeck wrote: > In a small bash script we have a trap to cleanup some files when exiting. You > run the script by ssh to the machine in question and execute the script. If > your ssh session dies the trap should trigger and clean up the files as the > script exit but this doesn't happen. I can reproduce this more-or-less exactly on bash-4.3.42 on Mac OS X, and it's a race condition. The read system call called by readline (read -e) either returns an error before sshd sends SIGHUP or it doesn't. When it errors before the SIGHUP, which appears to be the usual case, the read builtin returns and the EXIT trap gets called. The trap is executing (and is then killed) when the SIGHUP arrives. If you effectively ignore the HUP by trapping it with `true', the EXIT trap runs to conclusion just fine. If the SIGHUP arrives and kills the read builtin, the EXIT trap gets run when the fatal signal causes the shell to exit. You can see this if you change the SIGHUP trap to trap "echo HUP >> /tmp/trap" SIGHUP You'll see the HUP show up somewhere in /tmp/trap. The reason the 'trap cleanup HUP' doesn't work, though I can't reproduce that, is probably that the shell has exited -- without running any exit trap -- before the HUP arrives. Bash doesn't run the EXIT trap recursively, so it won't be re-executed as a result of the SIGHUP if it's already running as the result of the shell exiting normally. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
