The following script crashes bash versions 2.05, 3.2.25, 4.0.16,...
trap echo USR1caught USR1
read -t 1
foo=$( kill -USR1 $$ )
echo 'Yeah! no Segmentation fault!'
Cheers,
Marc
Hi,
It seems polling using read -t 0 is not supported. Apparently because the
implementation is based on alarm() (as opposed to be based on poll()/select()).
- is this true?
- if yes, doesn't this deserve more explicit documentation?
Would anyone know about an alternative, convenient way to
John Reiser a écrit :
On 08/04/2009 12:48 AM, fam...@icdsoft.com wrote:
First I would like to say that I'm not sure if this is a bug or a
feature of Bash.
If it is a feature, please let me know how to turn it off; or better
make it disabled by default...
The problem
Ivan Zahariev a écrit :
Same here, as Marc said.
I think that usually we are reading the script from a file and this is
the use-case we must focus on. Currently, we have the problem I
described when executing a script from a file and I think this must be
fixed/changed.
Hey, wait. I am
BuraphaLinux Server a écrit :
Not exactly what you asked for, but works the same:
#! /bin/bash
today() {
date
}
printf today is %s\n $(today)
exit 0
It is easier to just use $(date) directly though.
More direct, but less flexible.
printf arbitrary date is %s\n $(dateFunc)
Yang Zhang a écrit :
Why does assigning to multiple variables on the same line exhibit
sequential consistency normally but not for local variables?
You might be interested in another difference:
g ()
{
local x
x=$(exit 3); echo $?
local y=$(exit 3); echo $?
}
$ g
3
0
Stefano Lattarini a écrit :
I thought that when bash detect a syntax errors in a script,
it would pass a $? != 0 to the code in the exit trap, regardless
of whether `set -e' is active or not.
I think this can be classified as a bug in bash (in some
situations, a very nasty one). Please
Greg Wooledge a écrit :
On Wed, Aug 26, 2009 at 03:04:16PM -0400, Sam Steingold wrote:
foo=`ls`
echo $foo
echo $foo
What Greg did not explicitly said:
95% of the time you write $foo unquoted, you are wrong and should have
written double-quoted $foo instead.
This not just about newlines.
peter360 a écrit :
Thanks for the explanation. So my understanding of the way ssh works is
still incorrect. I am confused about at which point the two parameters,
-c and ulimit -a were converted into three, -c, ulimit, and -a. I
guess I need to read the source of ssh and bash to really
Greg Wooledge a écrit :
On Mon, Oct 05, 2009 at 07:55:33PM +0200, clemens fischer wrote:
{
... a number of commands
} 21 | ${prog_log} ${logfile}
If you're having trouble debugging your script, and you want to be
absolutely sure whether the commands in the braces are executing,
Bob Proulx a écrit :
Tamlyn1978 wrote:
Is there a way to make 'cat' ignore the comments or is there a better
alternative to cat in this case?
Note that if 'cat' didn't exactly reproduce the contents of input on
the output I would consider that a grave bug.
Well... GNU cat has a
jeng...@medozas.de a écrit :
Description:
bash enters into an infinite loop when the environment variable PWD
is unset. Probably not a smart thing to do, but since this variable
is so important, it should probably be ensured that it does not get
an empty value. (It
Jan Schampera a écrit :
Marc Herbert schrieb:
Repeat-By:
$ unset PWD
Fix = readonly PWD ?
This is not a fix, this is a workaround.
Sorry Jan: my suggestion was not addressed to you, it was addressed to the
maintainer.
The idea is to make PWD read-only *by default*.
On Mon, Oct 12, 2009 at 1:14 PM, Ralf Goertz
is it possible to have a process substitution with both input and output
redirection? So far I use the following work-around
cat parentprocess.sh:
#!/bin/bash
mkfifo fifo 2/dev/null
exec 5 (./subprocess.sh fifo)
exec 6 (cat fifo)
I think
Tobias Poschwatta a écrit :
In the following test case test1.sh, bash 4 behaves differently from
bash 3.1. The behaviour of bash 3.1 is what I would expect to be
correct. Is this a bug in bash 4 or an intentional change?
Isn't this related to this change?
Bob Proulx a écrit :
Todd Partridge wrote:
If the target has an appended '/' then the destination must be a directory.
But with cp (GNU coreutils) 6.12, appending '/' to the target does not seem
to make any difference?
I think the proper behavior here for 'cp -R test2 test' would be to
Jo King a écrit :
thanks for reply. agree it's not a
bug with bash.
i am inclinded to agree with the comments but bash is
popular and attracts a lot of newbies into scripting - a bit
of smart 'correction' of their wrong ways would at least
keep the cpu available for other processes (even a
The problem is dead-simple. You cannot run this command multiple times:
cp -R ./dirfoo ./dirfoo.backup
Sorry to add yet another (last) off topic message but I must do justice
to GNU cp. GNU cp actually does support the above thanks to a
(non-standard) option:
cp -R -T ./dirfoo
Stephane CHAZELAS a écrit :
By convention, _environment_ variables are upper-case, which helps
in a shell script to distinguish them with ordinary variables. I
would consider shell scripts with all upper-case variables to be
poorly written, and I agree with the fact that it looks like
yelling
Chet Ramey a écrit :
Functions were the last thing added to sh by Steve Bourne before he
left Bell Labs (he finished in 1983)
From Steve Bourne himself:
http://www.computerworld.com.au/article/279011/-z_programming_languages_bourne_shell_sh?pp=3
(very interesting interview)
Chet Ramey a écrit :
Sure. Since the status messages are written to stderr, you can save
file descriptor 2 and temporarily (or permanently, depending on your
needs) redirect it to /dev/null.
That means another subshell.
It doesn't require a subshell to save and restore stderr.
At first I
Greg Wooledge a écrit :
The problem being how to use set -e in a consistent manner across all
shells? You can't. set -e is unpredictable, unreliable, and should be
shunned. As you can see by the last dozen or so message on this mailing
list, not even bash gurus (other than Chet) can
Chris F.A. Johnson a écrit :
It isn't desirable. However, commands will sometimes fail; they
are intended to fail. Their failure provides necessary information
to the script.
Because it lacks proper exceptions, the language is indeed creating a
confusion between exceptional errors
Chet Ramey a écrit :
The fact that set -e is not the default looks like a big design
mistake to me.
Wow. That ship sailed 30 years ago.
but forgot set -e on the quay?
See also this ship:
http://www.reddit.com/r/programming/comments/7l89a/null_references_the_billion_dollar_mistake/
Marc Herbert a écrit :
Chris F.A. Johnson a écrit :
For example, if you want to know whether user 'john' is in the
password file:
grep -q ^john: /etc/passwd
You want to get the return code and execute code depending on the result
(which can be 0, 1 or 1; 'if grep
Hi,
I more or less assumed that section 3. Basic Shell Features is all
POSIX, in contrast to section 6. Bash Features which starts like this:
This section 6 describes features unique to Bash.
I think I was wrong. There seems to be at least two non-POSIX features
documented in the Basic section
Douglas Moyes a écrit :
I nearly brought down a server today.
# alias d=perl-script
A long time ago I read somewhere that aliases are not recommended. I
think they do not bring anything on the table compared to functions, do
they?
Anyway I have always done without them, but without
Eric Blake a écrit :
This is E4 in the FAQ:
ftp://ftp.cwru.edu/pub/bash/FAQ
POSIX permits, but does not require, that the final element of a pipeline
be executed in a subshell. Bash uses the subshell, ksh does not.
Variable assignments in a subshell do not affect the parent.
I am
Lhunath (Maarten B.) a écrit :
On 30 Nov 2009, at 11:34, Marc Herbert wrote:
Eric Blake a écrit :
This is E4 in the FAQ:
ftp://ftp.cwru.edu/pub/bash/FAQ
Instead of ''commands | read var''
Use ''read var (commands)''
I hardly see a need to change the existing implementation
Chris F.A. Johnson a écrit :
Why should it be the last element of a pipeline that is executed in
the current shell and not the first?
Because that's POSIX' choice?
Because the last element is the last one in the data stream. So it feels
more natural to get everything from the last
pjodrr wrote:
It would be nice if you explained what it is you're attempting to do, rather
than ask for a solution for what you're thinking would do that.
To be honest that is the first thing he (tried to) do:
pjodrr wrote:
how can I prefix every line of output of some command with a
Marc Herbert wrote:
What is wrong with the following:
prefix_with_date ()
{
while read; do
printf '%s: %s\n' $(date) $REPLY;
done
}
seq 4 | prefix_with_date
ls | prefix_with_date
Sorry I missed the fact that you want to run your commands in the current shell
pk a écrit :
I disagree. All the further changes in the requirements because creating a
subshell or being asynchronous is not acceptable etc. are not a goal in
themselves, but rather the indicators that he's trying to accomplish
something else.
I think he just want side-effects like in
Brian J. Murrell a écrit :
Is equally difficult?
Do you mean equally difficult as in impossible? Then I would say no,
it looks easier :-)
Or can I more easily play with FD duplication and redirection to
achieve that, even if it means adding a word at the end of things
I want on the real
empty_dir()
{
test x$(echo $1/*$2) = x$1'/*'$2
}
pk wrote:
This fails if the directory contains a file called *.
Yes. Unlike the ones below, empty_dir() above considers as empty a
directory that has a SINGLE element named '*'. Since I am not so
interested in files named '*', I think I
Sven Mascheck a écrit :
Chris F.A. Johnson wrote:
This has been discussed more than once in c.u.s; check the
archives.
and that's why we better discuss it here now?
I think Chris' message was more like: let's not discuss it at all and
just read the archives :-]
In case anyone is
Matias A. Fonzo a écrit :
On Fri, 11 Dec 2009 16:16:13 +
Marc Herbert marc.herb...@gmail.com wrote:
In case anyone is interested my winner (so far) is:
exists()
{
[ -e $1 -o -L $1 ]
}
The -L is redundant.
Not for me. I need -L because I want to consider broken symlinks just
Bernd Eggink a écrit :
To avoid misunderstandings, let me add that you are right (only) with
respect to variables being used _without_ declaration.
OK, but not having to explicitly declare variables is a feature that
most people expect from dynamic languages, so you can hardly blame them
for
mike bakhterev a écrit :
Description:
Something is wrong with variable substitution in the exec invocation.
When i try to close file descriptor whose number is in variable X with
command:
exec $X-
I think the operator is 2 as a whole; you cannot split
DennisW a écrit :
Also, don't use ls like this - it's eyes-only.
Here is a demonstration:
touch filename with spaces
ARRAY=( $(ls) ) # BUG
for f in ${arr...@]}; do echo file: $f; done
ARRAY=( * ) # OK
for f in ${arr...@]}; do echo file: $f; done
Gerard a écrit :
This is probably a dumb question; however, I have a question
regarding 'eval'.
If you know other programming languages, then it helps to consider
eval as a technique that generates code at run time (and
runs it immediately).
Sharuzzaman Ahmat Raslan a écrit :
Somehow, the backtick for foo() execute the function, echoing the correct
output, but fails to set the variable $gang to the correct value.
The variable is set, but in a different sub shell. backticks fork a sub shell.
By the way $( ) is preferred to
Jan Schampera a écrit :
Moreover, POSIX talks about newline here, which is a \n. Though I
didn't read through all the rationales, I just took a quick look, maybe
it's not limited to \n.
'\n' can be two characters outside of POSIX, see man fopen.
-
It would feel good to use
* means zero or more characters. It found zero and stopped.
I do not think that using a '*' star alone ever makes sense since it is
always matches.
The star is useful when anchored to something else. Like for instance
in: .*Khodabocus
'+' is a star anchored to something.
Anyway this has
pk a écrit :
Peng Yu wrote:
$0 gives the file name of the script. I could use several shell
command to get the directory where the script is in. But I'm wondering
if there is an easy-to-use variable that refers to the directory where
the script is in?
See this page:
Ian wrote:
The manual suggests I could move and close file descriptors with
[n]digit-
but I would need the equivalent of
command1 (...)-
Digit might very well mean (just a) digit but here the process
substitution, of course, is replaced with /dev/fd/63, say, certainly
not a
Eric Blake a écrit :
Another good reference is POSIX:
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_03
A less rigorous and easier reading is the Guide to Unix Shell Quoting:
http://www.mpi-inf.mpg.de/~uwe/lehre/unixffb/quoting-guide.html#para:sh-input-interp
Chet Ramey wrote:
To Posix, assignment statements never fail -- assignment errors cause
non- interactive shells to exit, period. In that case, it's possible
to reflect the exit status of a command substitution in the exit
status of a command consisting only of assignment statements,...
It's
Could this sentence:
An interactive shell is one started without non-option arguments,
unless -sis specified, without specifying 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.
be any more
Hi,
I could not find the dollar square brackets $[ ] expansion documented
in the manual. Is it the same as $(( )) ?
Cheers,
Marc
Le 22/03/2010 13:13, tbart...@gmx-topmail.de a écrit :
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Le 29/03/2010 14:50, Thomas Bartosik a écrit :
Please don't get me wrong. I have no problem in understanding the
man page this way, but I do think it is inconsistent.
It's a pity that square brackets are used both in the language itself
and in its syntactic definitions but this is bound to
Le 08/04/2010 22:58, Peng Yu a écrit :
I make the following directory and try to cd to it. But I can't. Could
you let me know what is the correct way of doing so?
$ mkdir environment\\-
$ cd environmen\\-
-bash: cd: environmen-: No such file or directory
In such situations I find
Le 15/04/2010 14:58, Clark J. Wang a écrit :
I don't understand why the $string was still splitted into words since
it's double quoted. Anyone can give a reasonable explanation?
set -x is often very good at giving explanations. Try this:
sh -x foo.sh
Le 03/05/2010 21:08, Kunszt Árpád a écrit :
http://mywiki.wooledge.org/BashPitfalls#cmd1_.26.26_cmd2_.7C.7C_cmd3
I read it, thanks. I understand it now.
I read man bash lots of times, but this behavior had escaped my
attention. There isn't any word about cmd1 cmd2 || cmd3 only the cmd1
Le 04/05/2010 14:40, Eric Blake a écrit :
Except that in computing tab completion, side effects are _all_ that
you want - basically, Freddie's problem is how to populate the
global completion variables from within helper functions.
Of course you want a side-effect in the caller, and my example
Le 16/04/2010 09:09, pk a écrit :
it looks like the gateway between this
group and the mailing list hasn't worked for a long time. Is this intended?
Was it announced somewhere?
Are you referring to the gmane group? If yes it has been working
perfectly for me over the last few months.
Except that it forks a subshell and consumes trailing newlines, and
the whole point of this exercise is to avoid forks and spurious
corruption of trailing newlines.
I will try to find an alternative to eval $( )
The code below allows the callee to return any kind of values (including
Le 07/05/2010 15:21, Peng Yu a écrit :
Would you please elaborate a little more on how to use LD_PRELOAD to
modify the call. If the library (for example, 'open' from stdlib.h)
is statically compiled in the binary, is LD_PRELOAD going to replace
it with a different 'open' function?
Header
Le 07/05/2010 16:02, Peng Yu a écrit :
I can copy the whole
directory and then modify one file in the newly copied N files. But
I'll lose track of which file has been changed later on, which is
important to me.
You will not lose track of the changed files: just run a recursive
diff comparing
Le 16/05/2010 16:51, Chris F.A. Johnson a écrit :
There are two characters that cannot be in a file or directory
name: / and NUL.
Interesting essay about this:
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
Le 21/05/2010 09:32, Linda Walsh a écrit :
I'm not sure if this is bash specific...I'd wager not, but I'm not sure where
to
put it.
I guess it is not.
I created an xfs file system with the naming version=ci, (case-ignore) flag.
This causes it to match filenames with case ignored.
So
Le 21/05/2010 16:25, Peng Yu a écrit :
When I type something after 'which', something means a command.
However, bash doesn't do command completion for the argument after
'which'. Is there a way to configure bash behave depending on the
context (in this case, do autocomplete after 'which')?
By
Le 24/05/2010 17:05, Lenga, Yair a écrit:
I would like to propose an improvement to the bash error handling:
Add flag/option err_return, that will cause a user defined shell
functions to immediately return, when a simple command will return a
non-zero status code.
The behavior is similar to
Le 16/06/2010 19:03, Greg Wooledge a écrit :
On Wed, Jun 16, 2010 at 07:47:03PM +0200, Krzysztof ??elechowski wrote:
The description of the read builtin [19] would benefit of the following note:
Warning: A pipeline of the form { echo 1 2 | read a b; } is not useful. Use
{
read1 2 a b; }
- The POSIX standard does allow echo 1 2 | read a b to be useful
(cf. 2.12 Shell Execution Environment).
Maybe the POSIX expect shell to execute the last command of pipeline
not in subshell.
From section 2.12 and from messages posted here in the past I
understand that POSIX allows
Le 02/08/2010 20:11, Bernd Eggink a écrit :
The other is that 'function' is clear and
self-explaining, while 'name()' wrongly suggests that function
parameters should be surrounded by parentheses.
... but only to people whose experience with Unix shells is close to
zero. Functions are not
Le 04/08/2010 09:27, Davide Brini a écrit :
From the Changelog:
This document details the changes between this version, bash-3.2-alpha,
and the previous version, bash-3.1-release.
...
3. New Features in Bash
...
f. Quoting the string argument to the [[ command's =~ operator now forces
Le 04/08/2010 11:39, Clark J. Wang a écrit :
Seems like I must explicitly use the `function' keyword to define foo() for
this scenario. Is that the correct behavior?
The correct behaviour is simply not to use aliases, since they bring nothing
to the table compared to functions. Have a look at
Le 04/08/2010 15:29, Clark J. Wang a écrit :
I do not agree. Aliases are much simpler to use than functions.
Please provide examples.
This is much more code:
F(){ find $@; }
This simple func definition will be 4 lines in my coding style. :) And I
like adding at least one blank line between functions.
Then just exclude .bashrc from your coding style.
Compare:
for a in $(echo 1 2); do echo x${a}x; done
x1 2x
for a in $(echo 1 2) ; do echo x${a}x; done
x1x
x2x
a=$(echo 1 2); echo x${a}x
x1 2x
a=$(echo 1 2); echo x${a}x
x1 2x
Shell quoting is difficult enough; why is such an inconsistency making
it even more confusing?
Uwe
What should a=* or a=$(echo 1 2) do?
Assign only the first file or just 1 to a? or result in an error?
Probably result in some error; I do not really care in this initial
stage. In any case it should not perform any *implicit* (and
thus confusing) quoting.
This hardly seem more consistent
Le 18/08/2010 12:14, Andreas Schwab a écrit :
Marc Herbert marc.herb...@gmail.com writes:
In any case it should not perform any *implicit* (and
thus confusing) quoting.
There is no quoting, the shell just doesn't split into words,
I know but it looks like quoting, because quoting is how you
Since inconsistency is basically not the same rule
everywhere, it typically shows in (good) documentation. Indeed:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06
2.6 Word Expansions
Not all expansions are performed on every word, as explained in the
On Thu, 12 Aug 2010 08:16:21 -0400, Greg Wooledge wool...@eeg.ccf.org
A return that's run in a subshell doesn't cause the parent shell to
return.
Granted but that does not mean it should behave like exit, instead it
could simply error like this:
$ return
bash: return: can only `return' from a
A return that's run in a subshell doesn't cause the parent shell to
return.
**SNIP**
Are there many people actually using
return to exit a subshell? That would not really make code easy to
read.
You misunderstood, or I was unclear.
*You* misunderstood, or I was unclear :-)
There is a big difference between
$ a=;
and
$ a=;
And for the VERY ignorant what is the difference
In the second case the unescaped semi-colon is a separator totally
unrelated to the assignment, which has no value at all. The variable
is assigned an empty string.
Le 24/09/2010 15:38, Greg Wooledge a écrit :
If this is turning into a general discussion of errexit (set -e) then
please also see
http://mywiki.wooledge.org/BashFAQ/105 and
http://fvue.nl/wiki/Bash:_Error_handling
These pages are great and should be read. But from experience, I
totally
Le 13/12/2010 19:48, Stephane CHAZELAS a écrit :
Yes, they're called commands or programs or software.
People tend to forget that before all a shell is a command line
interpreter.
If you're finding yourself writing complex shell functions that
don't make use of external commands, then
Le 17/12/2010 20:57, Bob Proulx a écrit :
CGI scripts are not normally setuid but are running as the web
server process owner
You wish...
Instead they stem from a script running unverified user provided
input. [...] It is a problem, and a big one, but completely different from
having a
Le 06/01/2011 09:48, Vidar Holen a écrit :
Finding the meaning of $? and $! in the man page is quite hard for people
not familiar with the layout and bash terminology (this frequently comes
up in Freenode #bash). It would be very helpful for them if you could
simply search for $! to find the
Le 10/01/2011 13:38, Greg Wooledge a écrit :
Don't use seq, ever, because it's Linux-only
and is a stupid way to count when bash has builtin integer arithmetic.)
seq is not exactly Linux-only but GNU-only.
GNU-specific versus bash-specific, which is worse? I'd say it
depends... on which
Le 10/01/2011 17:05, Roman Rakus a écrit :
I will say the same on both lists - why to execute another process if
you can do the same in the current one? No gain.
Not every for loop is in the critical path. Especially not in shell script.
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
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.
Since TERM is the
Le 14/02/2011 15:03, Dennis Williamson a écrit :
I'm having a discussion with someone who claims that for them on Bash
4.0.33, with compat31 *off*, they are getting 3.1 behavior with quoted
patterns in a =~ match.
They're saying that this:
[[ a =~ . ]] echo match || echo no
results in
Le 23/03/2011 20:28, Chet Ramey a écrit :
On 3/23/11 4:15 PM, Sam Liddicott wrote:
Yes. But a new subshell environment has been spawned. Each time that
happens BASH_SUBSHELL should increase.
Of course I know how it does work, but the man page isn't clear. It doesn't
say that the increase
Le 24/03/2011 14:50, Greg Wooledge a écrit :
On Thu, Mar 24, 2011 at 02:33:19PM +, Marc Herbert wrote:
I would also like to see this example in the documentation:
$ ( echo sub-$BASH_SUBSHELL ); echo main-$BASH_SUBSHELL
sub-1
main-0
Overkill.
Tradeoff.
Most of the other features
Le 07/04/2011 23:16, gmail a écrit :
I 'm not fully familiar with POSIX specifications regarding locales, for
now these specifications let me think that this behavior is expected and
that the
LANG environment variable is taken into account after the LC_*
environment variables
Would this
89 matches
Mail list logo
