Getting rid of "Terminated" message thanks to SIGINT
Le 30/01/2011 00:12, Chet Ramey a écrit : > Is it a problem? Bash prints messages about signal-terminated processes -- > Most people want to know when their jobs die ...except when they explicitly kill them. > at least those that don't die due to SIGINT or SIGPIPE -- when the > shell is not interactive. Wow! I wish I had known this very useful SIGINT trick earlier. Is it in a FAQ somewhere?
Re: Getting rid of "Terminated" message thanks to SIGINT
On 1/31/11 4:57 AM, Marc Herbert wrote: > Le 30/01/2011 00:12, Chet Ramey a écrit : >> Is it a problem? Bash prints messages about signal-terminated processes -- > >> Most people want to know when their jobs die > > ...except when they explicitly kill them. Then maybe the answer is to suppress the message when a process dies due to SIGTERM, as well as SIGINT. >> at least those that don't die due to SIGINT or SIGPIPE -- when the >> shell is not interactive. > > Wow! I wish I had known this very useful SIGINT trick earlier. Is it > in a FAQ somewhere? No. It's an IAQ, at best an OAQ. 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: libtool 2.4 args parsing incredibly slow
On 1/30/11 3:50 AM, Ralf Wildenhues wrote: > Hello, > > * Dan McGee wrote on Sun, Jan 30, 2011 at 01:04:17AM CET: >> On Sat, Jan 29, 2011 at 5:58 PM, Chet Ramey wrote: >>> On 1/25/11 10:08 PM, Peter O'Gorman wrote: for lt_wr_arg do case \$lt_wr_arg in --lt-*) ;; *) set x "$@" "$lt_wr_arg"; shift;; esac shift done > >>> This is a terribly inefficient function. > > Only if bash implements it inefficiently. It doesn't have to scale > nonlinearly with an efficient shell implementation that special-cases > this idiom which is, by the way, used quite a bit in Posix shell > scripts. If it's as common as you claim, it might be worth special-casing. The question is whether that's the case, and whether it's invoked with thousands of arguments enough to make the extra bookkeeping worthwhile. 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/
Inconsitent treatment of * (globbing)
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -march=i686 -mtune=generic -O2 -pipe -DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin' -DSTANDARD_UTILS_PATH='/usr/bin:/bin:/usr/sbin:/sbin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' uname output: Linux subiectiva 2.6.36-ARCH #1 SMP PREEMPT Mon Jan 24 18:34:55 UTC 2011 i686 Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.1 Patch Level: 9 Release Status: release Description: The way that "*" is treated for globbing is not consitent. Normaly a regular expression "*" would match all characters, but for the sake of usability it doesn't include the files which starts with a dot (dotfiles) and the file "..". This works correctly in bash. But if I use the expression ".*" in bash, I would expect from the behaviour of "*", that ".*" don't include the file "..". But the fact is, that it does in bash. This result in a strange (and unexpected) behaviour, because you're used to the behaviour of "*". Repeat-By: Go in a directory where you have read rights for "../*" and then execute the command "ls .*".
Re: libtool 2.4 args parsing incredibly slow
On Sat, Jan 29, 2011 at 5:58 PM, Chet Ramey wrote:
> On 1/25/11 10:08 PM, Peter O'Gorman wrote:
>> Hi,
>>
>> Dan reported a libtool performance regression in libtool-2.4 when running
>> his binaries with a large number of arguments.
>>
>> Libtool creates a shell script which usually sets some env vars and runs
>> the binary, new in recent libtool, the script also takes arguments, so
>> these have to be removed when execing the binary.
>>
>> Because forking is usually quite expensive, this shell function avoids forks:
>>
>> func_exec_program ()
>> {
>> for lt_wr_arg
>> do
>> case \$lt_wr_arg in
>> --lt-*) ;;
>> *) set x "$@" "$lt_wr_arg"; shift;;
>> esac
>> shift
>> done
>>
>> func_exec_program_core ${1+"$@"}
>> }
>
> This is a terribly inefficient function. You are re-evaluating "$@" for
> every argument. (That, for various reasons, gets expensive in bash
> because of translation between different internal representations and
> increases linearly with the number of positional parameters.)
>
> Why not use what bash gives you? Instead of reusing the positional
> parameters, use a second array. That would allow you to use the +=
> operator, do away with the dummy `x' and shift, and pass "${array[@]}"
> to the executed function.
Probably because this is not a bash-specific script but designed to
run in any sh interpreter.
-Dan
Re: Inconsitent treatment of * (globbing)
Pascal Wittmann writes: > The way that "*" is treated for globbing is not consitent. Normaly a > regular expression "*" > would match all characters, but for the sake of usability it doesn't > include the files > which starts with a dot (dotfiles) and the file "..". ".." is not in any way special here. It is just a file that happens to start with a dot. > But if I use the expression ".*" in bash, I would expect from the > behaviour of "*", that > ".*" don't include the file "..". ".." is matched by ".*" because it starts with a dot. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Inconsitent treatment of * (globbing)
On Sat, Jan 29, 2011 at 12:58:56PM +0100, Pascal Wittmann wrote: > But if I use the expression ".*" in bash, I would expect from the > behaviour of "*", that > ".*" don't include the file "..". But the fact is, that it does in bash. This is done for compatibility with all the other shells. If you want to get different behavior, try playing with bash's GLOBIGNORE variable: $ cd /tmp $ sh -c 'echo .*' . .. .AgentSockets .dcs.37dd79 .dcs.dcgtlock .dcs.trc1 .dcs.trc2 .dcs.utillock .mutt-imadev-16849-121.swp .x11start $ bash -c 'echo .*' . .AgentSockets .dcs.37dd79 .dcs.dcgtlock .dcs.trc1 .dcs.trc2 .dcs.utillock .mutt-imadev-16849-121.swp .x11start .. $ bash -c 'GLOBIGNORE=.:..; echo .*' .AgentSockets .dcs.37dd79 .dcs.dcgtlock .dcs.trc1 .dcs.trc2 .dcs.utillock .mutt-imadev-16849-121.swp .x11start
Re: Inconsitent treatment of * (globbing)
2011-01-31, 11:44(-05), Greg Wooledge: > On Sat, Jan 29, 2011 at 12:58:56PM +0100, Pascal Wittmann wrote: >> But if I use the expression ".*" in bash, I would expect from the >> behaviour of "*", that >> ".*" don't include the file "..". But the fact is, that it does in bash. > > This is done for compatibility with all the other shells. [...] All the other shells... but zsh and pdksh based ones (mksh, posh...) and shells like ksh93 can be globally modified by setting the FIGNORE environment variable (a bug and potential security vulnerability if you ask me). I agree with the OP that .* expanding "." and ".." is not useful but I suspect it is required by POSIX. -- Stephane
