Re: When a hashed pathname is deleted, search PATH
On Tue 18 Mar 2014 21:11:07 Linda Walsh wrote: > Mike Frysinger wrote: > > On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: > >> Chet Ramey wrote: > >>> Because the execution fails in a child process. You'd be able to fix it > >>> for that process, but would do nothing about the contents of the parent > >>> shell's hash table. > >>> > >>> The way the option works now is to check the hash lookups and delete > >>> anything that is no longer an executable file, then redo the lookup and > >>> hash the new value. > >> > >> > >> Wouldn't bash notice that the child exited in <.1 seconds ( > >> or is it less? > > > > as soon as you talk about trying to time something, you're obviously > > looking at it wrong. having a system that only works when the cpu/disk > > is fast and idle is a waste of time and bad for everyone. > > --- > > Um... this is a User Interface involving humans, and you are looking > for something that needs to be 100%? If this was a reactor control > program, that's one thing, but in deciding what solution to implement to > save some small lookup time or throw it away, an 90% solution is > probably fine. It's called a heuristic. AI machines use them. > Thinking people use them. Why should bash be different? except now you have useless knobs users don't want to deal with, and now your solution is "sometimes it works, sometimes it doesn't, so really you can't rely on it and you have to go back to the same system you've been using all along". trotting out other systems (like defense in depth) doesn't change the fact that your idea is flaky at best and is entirely user visible (unlike defense in depth strategies). i already highlighted a technical way of solving it 100% of the time. -mike signature.asc Description: This is a digitally signed message part.
ctrl-c does not send INT to all processes under foreground job
Hello, guys: It is said that "ctrl-C sends INT to ALL processes under foreground job", but i found a weird phenomenon. I have not read source code yet, but it does not seem to ascribe to what specification says. Test code is like: 1 trap "echo hello world $1" 2 2 sleep 1 3 /bin/bash $0 $(( $1 + 1 )) 4 echo "$1 go to sleep" 5 sleep 1000 6 echo "$1 exit " When I run ./test.sh on the console, the process (/bin/bash test.sh) is stuck at line 2. Then I input Ctrl-C, the result is that the code is interrupted at line 2 and goes to execute line 3, thus generate a new process (/bin/bash test.sh 1). At the same time, the first process (/bin/bash test.sh) is stuck at line 3 waiting for process '/bin/bash test.sh 1' to finish. At this time, I input Ctrl-C again, and generate process '/bin/bash test.sh 2', and i think process '/bin/bash test.sh 1' SHOULD BE SENT signal INT now. So I kill process '/bin/bash test.sh 2' by doing 'kill -9 '. What amazes me is that process '/bin/bash test.sh 1' did not trap INT this time, because "hello world 1" is not printed out. So it seems the process did not receive INT before. How can this be? Is it a bug? Br/ Ruan
Re: When a hashed pathname is deleted, search PATH
Mike Frysinger wrote: On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check the hash lookups and delete anything that is no longer an executable file, then redo the lookup and hash the new value. Wouldn't bash notice that the child exited in <.1 seconds ( or is it less? as soon as you talk about trying to time something, you're obviously looking at it wrong. having a system that only works when the cpu/disk is fast and idle is a waste of time and bad for everyone. --- Um... this is a User Interface involving humans, and you are looking for something that needs to be 100%? If this was a reactor control program, that's one thing, but in deciding what solution to implement to save some small lookup time or throw it away, an 90% solution is probably fine. It's called a heuristic. AI machines use them. Thinking people use them. Why should bash be different? Fixing it isn't about 0/100% fixed, but a combination of actual cost, (measurable impact), user perception, and programmer cost to implement something that works for most. As you drive up the 'perfection rate' or 'uptime' to another 9 (i.e. 90% to 99, or 99 to 99.9%) the costs usually go up exponentially. If it costs 1 day to implement an 90% algorithm, a 99% algorithm easily be a 1-3 month project depending on how you measure. 99.9 could could involve a year or more. In security even though systems per proved to lower levels of assurance, no computer system was ever validated to the level of A1 - mathematical proof. The cost was too prohibitive. Same goes for software design and fixes. I'm more often one to rat-hole on small stuff while missing big stuff, but even I can see that a less than "perfect" solution would achieve most of the original design goals, presuming they are still necessary on today's machines. If you have a machine that can't do a path lookup in <.1 seconds, Then walking a PATH env var to do multiple path lookups is gonna hurt that many times more. If your system is so slow that everything is bad, then having hashing turned on at all seems a rather unimportant issue.
Re: bash cross with installed readline
On Sun 16 Mar 2014 13:30:55 Andrew Kosteltsev wrote:
> When we build bash for some targets the INCLUDES variable for BUILD_CC
> contains the path to target readline headers. This path points to the
> target headers which not preferred for utilities which prepared for build
> machine.
>
> Also when we have installed readline on the target the configure script
> avoids cross_compilation problems with AC_TRY_RUN and substitutes wrong
> (very old) version of libreadline. If we sure that we installed correct
> readline version we can change configure script for cross compilation
> process.
>
> Please look at attached patches. If this solution can be used for common
> case then please apply these patches for the future versions of bash.
i haven't seen the issues you describe for the first patch. maybe it's
because i don't pass full paths to the target readline but instead let the
toolchain find it for me. so there is never any -I flag mixing.
the 2nd patch is the wrong way to approach the problem. change the AC_TRY_RUN
into an AC_TRY_COMPILE test by relying on RL_VERSION_{MAJOR,MINOR} being
defined and doing an incremental search for its value. see how autoconf
implements its AC_CHECK_SIZEOF macro using only compile tests for the
algorithm.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: When a hashed pathname is deleted, search PATH
On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote: > Chet Ramey wrote: > > Because the execution fails in a child process. You'd be able to fix it > > for that process, but would do nothing about the contents of the parent > > shell's hash table. > > > > The way the option works now is to check the hash lookups and delete > > anything that is no longer an executable file, then redo the lookup and > > hash the new value. > > > Wouldn't bash notice that the child exited in <.1 seconds ( > or is it less? as soon as you talk about trying to time something, you're obviously looking at it wrong. having a system that only works when the cpu/disk is fast and idle is a waste of time and bad for everyone. if bash could rely on real time signals, sigqueue could be used to send a signal with attached info (like ENOEXEC) and the parent could look for that. alternatively, accept that it's not a real problem in practice for the majority of people as Chet has pointed out ;). -mike signature.asc Description: This is a digitally signed message part.
Re: ${assoc[key]+set} no longer works.
On 3/18/14 5:36 AM, geir.ha...@gmail.com wrote:
> Bash Version: 4.3
> Patch Level: 0
> Release Status: release
>
> Description:
> With an associative array, assoc, ${assoc[key]+set} expands to the
> empty string if the associated value is the empty string.
Thanks for the report. This was a consequence of a change made back in
2011 to expand the value portion of the assignment statement a slightly
different way. I've attached a patch to fix it.
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/
*** ../bash-4.3/arrayfunc.c 2013-08-02 16:19:59.0 -0400
--- arrayfunc.c 2014-03-18 11:08:15.0 -0400
***
*** 598,601
--- 598,606
{
val = expand_assignment_string_to_string (val, 0);
+ if (val == 0)
+ {
+ val = (char *)xmalloc (1);
+ val[0] = '\0'; /* like do_assignment_internal */
+ }
free_val = 1;
}
regression: extglobs expand hidden files in 4.3
With bash-4.3 as found on Debian's 4.3-2 package: $ bash -cO extglob 'echo *(.)' . .. $ bash -cO extglob 'echo *(foo)*' . .. a $ bash -cO extglob 'echo @(|foo)*' . .. a It looks like the regression was introduced by 4.3, as 4.2 doesn't exhibit the same problem. This one's OK: $ bash -cO extglob 'echo ?(foo)*' a regards, Stephane
Re: Following symlinks in globstar
2014-02-04 09:23:21 -0500, Chet Ramey: > On 1/25/14 6:11 PM, Stephane Chazelas wrote: > > 2014-01-21 10:19:10 -0500, Chet Ramey: > > [...] > >>> I am not so worried about the method used to "fix" globstar -- whether > >>> we keep backwards compatibility or not -- I am more concerned that we > >>> have at least *some* way of disabling what many people view as > >>> undesirable behaviour. > [...] > > I agree with Chris that the bash behaviour here is not > > desirable. There's a number of articles on usenet or > > unix.stackexchange.com (many by me sorry, > > http://unix.stackexchange.com/search?q=bash+globstar+symlink) > > that say that the bash behaviour is broken in that regard and > > that globstar from other shells should be used instead. > > I put in a tentative change; we will see how it works. [...] That looks a lot better indeed. Thanks Chet. regards, Stephane
Re: When a hashed pathname is deleted, search PATH
On 18 March 2014 08:04, Linda Walsh wrote: > > > Chet Ramey wrote: > >> Because the execution fails in a child process. You'd be able to fix it >> for that process, but would do nothing about the contents of the parent >> shell's hash table. >> >> The way the option works now is to check the hash lookups and delete >> anything that is no longer an executable file, then redo the lookup and >> hash the new value. >> > > Wouldn't bash notice that the child exited in <.1 seconds ( > or is it less? > Timing is not something you could rely on, though. The child could report failure by e.g. writing through a pipe to the parent, as in http://stackoverflow.com/questions/2719499/c-signal-parent-process-from-childthereby letting the parent update its hash table, but it's not clearly worth the extra complexity to remove the small overhead.
${assoc[key]+set} no longer works.
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux gina 3.2.0-59-generic #90-Ubuntu SMP Tue Jan 7 22:43:51 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 0
Release Status: release
Description:
With an associative array, assoc, ${assoc[key]+set} expands to the
empty string if the associated value is the empty string.
Repeat-By:
$ declare -A assoc='([x]= [y]="1" )'
$ printf '<%s>\n' "${assoc[x]+x is a key}" "${assoc[y]+y is a key}"
<>
Re: When a hashed pathname is deleted, search PATH
Chet Ramey wrote: Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check the hash lookups and delete anything that is no longer an executable file, then redo the lookup and hash the new value. Wouldn't bash notice that the child exited in <.1 seconds ( or is it less? I.e. if bash spawns a child for an exec and gets a sigchild from it < (some small value of time) later, THEN it could check the path that was just executed ??? That would keep any side performance hits to a rather small number of cases with relatively few false positives. The up side is the delay in the parent would only happen AFTER a command has been attempted, and immediately failed. I think a further lookup in the parent should happen in < 1ms given that the path lookup just happened in the child and most OS's would have cached the path lookup when the child did it. I.e. - the parent would have next to zero delay in rewalking a "hot" path.
