Re: Bash bug with ints beyond 2147483646
Greg Wooledge wrote:
On Tue, Nov 02, 2010 at 03:48:49PM -0400, Pete Gregory wrote:
echo {2147483640..2147483647}
dies with a malloc error
In bash 4.1.9 under HP-UX 10.20, it consumes all available CPU until
I kill it with SIGKILL. (I suppose there's a chance it might eventually
have died due to malloc errors or whatever, but after several minutes
of waiting, I got impatient.)
Maybe as an additional hint for Chets debugging: In 3.2.39(1)-release it
works, in 4.1.2(1)-release it fails (yes, Bonsai just came back from
paging...). It drives crazy and mallocs like hell... 32bit int overflow?
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: static vs. dynamic scoping
Eric Blake wrote: In static scoping, function f2 does not shadow a declaration of a, so references to $a within f2 refer to the global variable. The local variable a of f1 can only be accessed within f1; the behavior of f2 is the same no matter how it was reached. If it matters (I already know Chet's answer): I agree with Mr. Korn here about sanity. Infact, for some reason, I always intuitively relied on it (without any problem for now - I didn't hit a case), maybe I intuitively expected the C behaviour from Bash. In Bash practise, now as I know it, I can code accordingly. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Bug report
sworddrag...@aol.com wrote: Description: It is possible to make input with the keyboard before bash is fully initialized. This problem is critical on password inputs like the linux login. Repeat-By: $input is now shown before and after sworddra...@ubuntu:~$. Example: testsworddra...@ubuntu:~$ test Fix: I think bash should lock all input until it is fully initialized and maybe draw all locked input after unlocking. What makes you think Bash is initialized WHILE you login (and not AFTER)? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: ionice bash pid in bash_profile Fails
Roger wrote: If you want the PID of the current shell process, use $$ instead. Yes I do. It's only me on this computer, unless you're speculating on prioritizing a snooper. :-O This is (in this context) not related to the number pf "bash" processes running. Not at all. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Referencing empty array with "set -u" active throws error
jens.schmid...@arcor.de wrote: For an empty "$@" this does not throw an "unbound" error, which seems to be an inconsistent behaviour to me. -u Treat unset variables as an error when substituting. I think the behaviour is consistent with the documentation. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: quotes invade positional parameters
jida...@jidanni.org wrote: $ cat 201012contract #!/bin/sh -eux set a b c d e f : ''$@'' : ' '$@' ' : ''$*'' : '' $* '' : " "$* " " $ ./201012contract + set a b c d e f + : a b c d e f + : ' a' b c d e 'f ' + : 'a' b c d e 'f' + : '' a b c d e f '' + : ' a' b c d e f ' ' $ apt-show-versions bash bash/unstable uptodate 4.1-3 OK, the problem may only be -x deep, affecting the -x reporting output, but not the actual functionality, thank G.O.D. I'd say this is expected (and by the way it's not only on set -x). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: nounset option does not work with array in arithmentic expressions
Joerg Boehmer wrote: The value of variable ar[1] is expanded to 0 although it was not set. The full syntax produces the expected behavior: The value of y is 0, since you operate in arithmetic context. This is fine. But I definitely agree it should bail out here. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: quotes invade positional parameters
jida...@jidanni.org wrote: Well anyway, it would be 'no skin off of bash's back' if it just reported what it was given. If it was given ' 'a b c it should report ' 'a b c and not just 'assume' we prefer ' a' b c or ' a' 'b' 'c' etc. Just as legitimate and doesn't cause calls in the middle of the night from the old folks home. Wait, that stage of the program doesn't know it was given that, and to make it know would just increase complexity. As would reporting \ \ a b c or would it... OK, never mind. Yea, that's it. It doesn't report what's given, it reports the result of the processing. This is hopefully similar, but definitely not the same. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Referencing empty array with "set -u" active throws error
jens.schmid...@arcor.de wrote: -u Treat unset variables as an error when substituting. I think the behaviour is consistent with the documentation. The question is rather when to consider a variable set or unset. I'm not sure about the intended meaning here, but I don't consiter $@ as a variable (but a special parameter). Though regarding what Chet said to this topic before, maybe the documentation should be rephrased. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Word splitting and arithmetic expansion
Hello list, maybe something for old stagers. Bash (and POSIX, and Korn, ...) do field/word splitting on the result of arithmetic expansions. This is fine, the behaviour per se is not a problem at all. However, I wonder about the original thought behind it: Is there a specific reason or need to let the shell split an arithmetic expansion result? Or was it just consistency for Korn, "everything is splitted, except the expansions where it makes no sense, like pathname expansion" - should I just take it "as is"? Or even older shells that split everything? Neither the POSIX rationale nor older Korn or shell portability documents I found had any hint about the background - maybe you have? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Word splitting and arithmetic expansion
Chet Ramey wrote: Arithmetic expansion is a Posix invention. It's treated just like every other expansion: split unless double quoted. There's no compelling reason to make it behave differently. I don't want it to behave differently :) Okay, so it's just "as is", because by consistent design all expansions are subject to WS (with some exceptions). Pathname expansion happens after word splitting. Tilde expansion is the one that's not subject to word splitting. This is clear, it was an unlucky example (pathname expansion's location in the processing is where it is to prevent WS, but tilde expansion is a better example since it happens before WS and is excluded from WS). Thanks. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
read builtin and readonly variables
Hello list, the read builtin command, when trying to assign to a readonly variable after reading the data, spits an error message. This is fine. But the return status is 0. It "always" (down to 2.04 was tested) has been like that, and it's like that in upcoming 4.2. For me, this doesn't make sense. The read may have been successful, but the data is gone. It would make sense to return !=0 here, IMHO. I also quickly cross-read POSIX, since such weirdness usually comes from there ;-) but I didn't see anything obvious. Regards, Jan -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Huge execution time in 4.2, WAS: for; do; done regression ?
Alexander Tiurin wrote: ~$ time for i in `seq 0 1` ; do echo /o/23/4 | cut -d'/' -f2 ; done > /dev/null To track this a bit, I ran the exact command several times in a Bash 3.2, seeing increasing execution times (40s up to ~2min), as reported. I knew there were several bugs about filedescriptors and leaks fixed since then, so I tested it in 4.2 beta. The first run took about 27 minutes(!), the second run still goes on. I can't imagine this is just some debugging code still active (it's a beta). Anybody else able to reproduce this? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Huge execution time in 4.2, WAS: for; do; done regression ?
Chet Ramey wrote: I can't imagine this is just some debugging code still active (it's a beta). Imagine. Anything that doesn't have a version tag of `release' has DEBUG enabled for the preprocessor, which enables MALLOC_DEBUG. If you're using the bash malloc, MALLOC_DEBUG turns on extensive memory checking and allocation tracing. All active allocations are kept in a hash table with 8K entries, and when you fill up that hash table, each new allocation has to search the entire table before throwing away an old entry. That quickly degenerates. This can be fixed, but it hasn't become a priority yet. Wow. A huge difference. Anyways, if you tell me how I'll try to track it down, but I read in the other thread you already try to gprof it. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
'help set' missing '--'
Hello, the help output for the set builtin command misses '--'. The manpage is ok. (recognized by 'yitz' on irc://irc.freenode.net/#bash) -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: 'help set' missing '--'
Greg Wooledge wrote: Or: set [-abefhkmnptuvxBCHP] [-o option-name] [--] [arg ...] More: set [-abefhkmnptuvxBCHP] [-o option-name] [-] [--] [arg ...] Plus: Describe '--' the same way '-' is described (with an extra part in the full help message below the synopsis). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: 'help set' missing '--'
Dennis Williamson wrote: I think this distinction from the man page is what's missing in the help: > [...] Exactly. Thanks for pointing it out, I thought it was clear :) -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: for; do; done regression ?
Marc Herbert wrote: seq is not exactly Linux-only but GNU-only. GNU-specific versus bash-specific, which is worse? I'd say it depends... on which mailing-list you post :-) I'd say a script interpreted by the GNU shell must not rely blindly on GNU tools being installed or on running on a GNU OS. It can, however, rely on Bash features, of course. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Here strings and pathname expansion
Hello world,
I recently answered a question about using the asterisk mixed with
redirection and other words. This also lead me to the documentation that
states (REDIRECTION section):
---
The word following the redirection operator in the following
descriptions, unless otherwise noted, is subjected to brace expansion,
tilde expansion, parameter expansion, command substitution, arithmetic
expansion, quote removal, pathname expansion, and word splitting. If it
expands to more than one word, bash reports an error.
---
This is true, for here documents the exceptions are mentioned. However,
for here strings no exceptions are mentioned ("The WORD is expanded
[...]]", but the WORD is at least not subject to pathname expansion:
$ cat <<< *
*
This is EITHER
(a) a documentation mistake OR
(b) a bug
Case (a) is clear, the exception is not mentioned.
Case (b) is also possible, because it COULD be intended to
pathname-expand WORD:
(1) error out if pathname expansion results in more than one word OR
(2) use the first word of the result OR
(3) pass all results (as a special case)
I would expect the thing to either be (a) or (b)(2).
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: Here strings and pathname expansion
Roman Rakus wrote: It is noted in Here Documents (and Here Strings is a variant of here documents). And there is: No parameter expansion, command substitution, arithmetic expansion, or pathname expansion is performed on word. This is not true for here strings (infact, it wouldn't make sense for here strings to disallow for example parameter expansion). I see the relation to here documents. I just tried to point out that either thze documentation or the behaviour should be revised. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Bash source repository
Bradley M. Kuhn wrote: I humbly suggest that http://git.savannah.gnu.org/cgit/bash.git be replaced with this repository above that I've created. The new repository contains everything that the current Savannah one does, but I put much more effort into making commits fine-grained, rather than merely importing the public releases blindly. (For example, I did 'git mv' where it was obvious a move occurred, so that changes in file movements were properly tracked historically). A good work. I agree with using this as a base to reflect future development. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: documentation bug re character range expressions
Hi, just as side note, not meant to touch the maintainer discussion. This is not only a "Bash problem". The programmer/user mistake to use [A-Z] for "only capital letters, capital A to capital Z" is a very common one. But I'm not sure if every official application-level documentation should cover those kind of pitfalls. There would be many topics around "bad programming habbits" that should be documented. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Question about testing with variable operators
Andreas Schwab wrote: "Steven W. Orr" writes: As a work around, I can use eval or the builtin test, but my question is this: Is this a bug or is there a reason that it should work for arithmetic but not for the test [[ operator? [[ is a reserved word like if, which triggers special parsing rules, so you cannot use it like this. However, it should work for the good ol' test command ([ ... ]) -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Permission denied to execute script that is world executable
John Williams wrote: I find that I cannot execute world-executable scripts when they are in a directory which is mounted on a drive on an HBA (host bus adapter Can you show the mount options of the filesystem? -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: printf treats arguments of "%c" not as expected
Hi, I agree this is not a bug. %c works as described. However, Mr. Wang may want to read one of Greg's brilliant FAQ entries [1]. In general it's a bit of a pity that printf can do character->number conversion, but not (directly) back. But it is like it is and the "workarounds" are not really complicated. Jan [1] http://mywiki.wooledge.org/BashFAQ/071 -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: printf treats arguments of "%c" not as expected
Yunfeng Wang wrote: Perhaps bash should clarify this issue in its documents such that users like me would not be misguided again. Since the reference to printf(3) is misleading sometimes, I made some document [1] for Bash's printf only. It's far from perfect, but at least it mentions %s and "first character" ;-) Jan [1] http://wiki.bash-hackers.org/commands/builtin/printf -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: sorry--this is my question
On 22.07.2011 18:12, the mad doctor kaeding wrote: is this a bug? echo goodbye\ cruel\ world\! goodbye cruel world! echo "goodbye cruel world!" bash: !": event not found echo "goodbye cruel world\!" goodbye cruel world\! No, this is a specific history expansion in interactive shells. Execute ''set +H'' and try again (it's disabled in non-interactive shells). -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Massive recursion -> SEGV
Hi folks,
a suggestion about recursive function calls (and not only that, of course).
Do you see a way for Bash to pull the emergency break before it runs out
of stack here (to provide an error to the user, rather than a crash):
f1() {
f1
}
f1
Currently it runs into a SEGV, where the number of recurions depends on
the stack limit.
On a fast search I found no portable way, but there are ways for
specific platforms, like getrusage() when stack is reported there.
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Re: Massive recursion -> SEGV
On 01.07.2012 14:37, Roman Rakus wrote: Look for FUNCNEST variable. In recent release it is available. I more meant the shell interpreter, less the code I can write. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Massive recursion -> SEGV
On 02.07.2012 15:57, Eric Blake wrote: Look for FUNCNEST variable. In recent release it is available. I more meant the shell interpreter, less the code I can write. It would be possible to link bash with libsigsegv to install a graceful stack overflow handler that allows a nicer exit message on failure; other GNU projects that have done so include awk and m4. But short of introducing arbitrary limits (which goes against GNU philosophy), it is not possible to detect stack overflow until after it happens, and the only recovery possible after detecting stack overflow is a graceful message and exit unless you go to extreme lengths to block signals around every call to malloc or any other library function that grabs a lock. Hi Eric, yes, it's more about helpful messages (not neccesarily a recovery), less about limits in Bash or application (script, etc.). The origin of this all was a "bugreport" to me about the manual lying about no limits on recursion - it turned out it was massive recursion and little stack - and a resulting SEGV. I'm interested in people's thoughts there, like is it okay to just crash or would a message be better? libsigsegv - I'll have a look. Thanks. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Massive recursion -> SEGV
On 02.07.2012 20:57, Chet Ramey wrote: On 7/2/12 2:36 PM, Jan Schampera wrote: The origin of this all was a "bugreport" to me about the manual lying about no limits on recursion That's funny. Aye. A bit of confusion. -- Be conservative in what you do, be liberal in what you accept from others. - jbp, master of the net, in RFC793
Re: Undocumented behaviour - parameter expansion ${par-word}
On 04.09.2012 13:13, Roman Rakus wrote:
Hi,
Petr, adding to cc: list, found behaviour not documented, neither in man
page nor bash ref manual:
${par-word} will do expansion of par, and if the par is unset it is
substituted by word. It is different from ${par:-word}, where word is
used when par is unset or null.
Is it undocumented and deprecated, like $[]? Or just undocumented?
Hi Roman,
it actually is documented (and it's more general, not limited to "-")
[...]
When not performing substring expansion, using the forms documented
below, bash tests for a parameter that is unset or null. Omitting the
colon results in a test only for a parameter that is unset.
[...]
--
Be conservative in what you do, be liberal in what you accept from others.
- jbp, master of the net, in RFC793
Suggestion: Documentation: ulimit -f
Hi folks. Currently, the documentation (both, help-command and manpage) on ulimit -f says: "The maximum size of files created by the shell" which may make one think of, it only affects files that are created from the shell itself. Assuming -f works like it should work, a text like: "The maximum size of files created by the shell and its child processes" might be better. I know that the description of ulimit itself mentiones that. But the -f description is the only one that says "by the shell". Best regards, Jan -- Live as if your were to die tomorrow. Learn as if you were to live forever. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Arithmetic expressions and parameters with newlines breaks
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux mainserver 2.6.18-4-486 #1 Wed May 9 22:23:40 UTC 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: Parameters inside arithmetic contexts like $(()) and (()) break the expression parsing when they contain a newline Repeat-By: $ foo="12 > 34" $ echo $((foo)) bash: 12 34: syntax error in expression (error token is "34") $ ((foo)) bash: ((: 12 34: syntax error in expression (error token is "34") Fix: ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Fw: Arithmetic expressions and parameters with newlines breaks
Begin forwarded message: Date: Mon, 2 Jul 2007 18:32:49 +0200 From: Jan Schampera <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] (Bob Proulx) Subject: Re: Arithmetic expressions and parameters with newlines breaks On Mon, 2 Jul 2007 10:08:08 -0600 [EMAIL PROTECTED] (Bob Proulx) wrote: > What behavior did you expect to see when the evaluated expression > contained whitespace? What would you expect from "12 34"? It is not > a number. It is two numbers. There is no operator between them such > as "12 + 34" or other. > > What other result than a syntax error is possible here? Hi Bob, thanks for your reply! Well, I guess intuitively expected that it evaluates to 0, like for example: $ test=string $ echo $((test)) 0 But I just made some experiments (which I should have done before) and read the manual again a bit closer: In this example I really reference the variable "string" (as designated operand) which is unset/null and thus evaluates to 0. I also saw this can be done in any depth. So, excuse my wrong interpretion of the manual (maybe that needs to be marked extra by a sentence or a half in manual). It's definitely not a bug (it is - between screen and chair!). Best regards and thanks again for quick reply, Jan ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: "bashbug" script
On Thu, 2 Aug 2007 09:29:19 -0400
Chet Ramey <[EMAIL PROTECTED]> wrote:
> > Here was an interesting bug which was some what unexpected.
> >
> > cat <(find ./ -iname t{1,2,3})
> >
> > this is a valid command according to bash due to a bugged expansion
> > of {1,2,3} and the process expansion. It becomes three commands:
> >
> > find ./ -iname t1
> > find ./ -iname t2
> > find ./ -iname t3
>
> It's not a bug. Brace expansion is the first word expansion
> performed, and can potentially expand one word to multiple ones. If
> you want to defer the brace expansion until the command in the
> process substitution is executed, add a backslash before the open
> brace.
>
> Chet
>
Hi Chet,
I intentionally expected <() and >() to be as protected as $() is. Is
there a specific reason for them to not be protected against the
initial parsing? Compatiblity to some other shell maybe?
Or do I get that all wrong?
J.
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Re: time builtin handles backgrounding poorly
Jack Lloyd wrote: Description: The time builtin seems to be confused if something is backgrounded, and prints immediately the time rather than waiting for the job to complete. I found this very unexpected. Repeat-By: $ time sleep 5 # hit C-Z to stop the job before 5 seconds [1]+ Stopped sleep 5 real0m0.525s user0m0.000s sys 0m0.000s $ fg sleep 5 # the 5 second sleep continues $ I guess that's due to the fact that `time' is not a builtin command, but belongs to the syntax of a pipeline (as in grammar defs). Though I know where it comes from, I don't know if that behaviour can be changed somehow, I'm not that familiar with the Bash itself. J.
Re: Web urls cannot be accessed from Bash Terminal
Pratiksha Powar wrote: Description: Yum not able to access url through bash Repeat-By: Following is the sequence of commands and the results: 1. [EMAIL PROTECTED] /]# yum install gcc 2. Loading "installonlyn" plugin 3. Setting up Install Process 4. Setting up repositories 5. Could not retrieve mirrorlist http://apt.sw.be/redhat/el5/en/mirrors-rpmforge error was 6. [Errno 4] IOError: 7. Error: Cannot find a valid baseurl for repo: rpmforge I don't know whether it is a problem with Bash or yum. I suppose it is bash only. Also, if I need to upgrade to the latest version of Bash where would I get a reliable binary for the above stated architecture. No, this is not a Bash problem. Not everything that happens on a terminal or terminal emulator is automatically the Bash shell. J.
Re: Missing character when using ${VAR:1} and length(VAR)==1
Chet Ramey wrote:
Description:
there is missing a charachter when using the following:
# TT="oo"; echo "l${TT:1}l"
lol
# TT="o"; echo "l${TT:1}l"
l
I can't reproduce this; I get `ll' from the second expansion.
I can't reproduce it on a 2.05b:
$ TT="o"; echo "l${TT:1}l"
ll
But I can reproduce it (or at least something weird) on a 3.1.17(1)-release:
$ TT="o"; echo "l${TT:1}l"
lXl
(where X is a non-printable character for my terminal here, maybe multibyte)
However, I can't reproduce it on the latest build, so I assume it's fixed.
J.
Re: Linux: bash 'declare -f' adds trailing whitespaces to output
Jari Aalto wrote:
testfunc () $
{ $
echo "this is test"$
}$
Just a thought:
It looks like there is a system behind it. So I guess it's some parser
thing that needs it like that.
However, just guessing.
Jan
Re: using NUL in scripts
Mike Frysinger schrieb:
> is it even possible to utilize NUL in scripts ? or does bash just strip it
> out ? for example, trying to work with binary data:
> foo=$( echo "${foo}" > new-file
> the "new-file" will be exactly "binary-file" if all NUL bytes are stripped out
>
> or perhaps i want to take an arg list, append a string, and run a command on
> it ... but i cant pass it straight as it may be too large, so i need to xargs
> it ... so i'd do something like:
> echo ${@/%.moo/.foo$'\000'} | xargs -0 rm -f
> but this doesnt work since the $'\000' gets stripped
> -mike
We also once inspected that (more general "binary data"), the result was:
http://wooledge.org/mywiki/BashFAQ/058
J.
Re: bash -n doesn't seem to catch all syntax errors...
Ken Failbus wrote: > When I specify on command-line "bash -n ". Bash doesn't > check for valid syntax errors. E.g. if variable is missing a "$" infront > of it while assigning a value. This is not catched by bash. > ### example code > p=hello > e=world > If [ p != $e ];then > echo "not equal" > else > echo "equals" > fi This is perfectly valid code, it would be an error/bug to complain here, on a syntax check. Also you should use more quotes for your parameter expansions: - http://bash-hackers.org/wiki/doku.php?id=syntax:words - http://www.grymoire.com/Unix/Quote.html J.
Re: Can't unset function with unusual names
Andreas Schwab wrote:
>> $ unset .foo-bar
>> bash: unset: `.foo-bar': not a valid identifier
>
> Use unset -f.
IMHO there is a bug. The docs say that ''unset'' without a specific
switch affects variables AND functions, hence it should allow the names
for both (or it should ONLY affect variables and expect an explicit -f
for functions).
The latter behaviour would be POSIX-compilant, too ("unspecified" opens
doors - heh).
It's at least a usability bug.
J.
Re: Looping through lines with tabs of file with cat
yitzle wrote: > fileIn="blah" > for i in "$(cat $fileIn)" > do > echo $i > echo > done Check out http://wooledge.org/mywiki/BashFAQ#faq1 J.
[BUG?] read -n limits bytes, not characters
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux mainserver 2.6.18-5-486 #1 Tue Oct 2 23:38:54 UTC 2007 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: read -n limits bytes, not characters Repeat-By: read -n1 <<< '(some weird unicode character)' echo "$REPLY" Also tested with 3.2 patchlevel 25 (IIRC). The documentation says /- | -n nchars |read returns after reading nchars characters rather than waiting |for a complete line of input. \- If it's the intended behaviour, the documentation should be changed. I can't provide a fix, sorry. Ah yes, my locale: /- | LANG=de_DE.UTF-8 | LC_CTYPE="de_DE.UTF-8" | LC_NUMERIC="de_DE.UTF-8" | LC_TIME="de_DE.UTF-8" | LC_COLLATE="de_DE.UTF-8" | LC_MONETARY="de_DE.UTF-8" | LC_MESSAGES="de_DE.UTF-8" | LC_PAPER="de_DE.UTF-8" | LC_NAME="de_DE.UTF-8" | LC_ADDRESS="de_DE.UTF-8" | LC_TELEPHONE="de_DE.UTF-8" | LC_MEASUREMENT="de_DE.UTF-8" | LC_IDENTIFICATION="de_DE.UTF-8" | LC_ALL= \- -- This is my life - this is my net! - Jan
Re: Tilde expandion for values of long options
Per Starbäck wrote: > Repeat-By: > echo foo=~root => foo=/root > echo --foo=~root=> --foo=~root > > In the second one there is no expansion. >From my understanding of the manpage and the SUS the first one is "wrong", it should not be expanded. I don't say it's useless, I just say "from my understanding of the manpage and SUS". J.
Re: Segmentation fault
Chet Ramey wrote:
> seba wrote:
>> #!/bin/sh
>>
>> fib() {
> You managed to write yourself an infinitely-recursive function, and
> eventually ran out of stack space. `==' is a string operator, not a
> numeric operator, when used with `['.
Most likely. When I test this and it breaks, the stack has over 32000
entries, all execute_command(), execute_command_internal().
J.
Re: bash does not jump where it is supposed to jump
William Tambe wrote:
> The code below should only print end
> [ "test" = "test" ] && {
> # after the false command bash should jump directly to echo end
> # but instead run echo echo "test != test"
> false
> } || {
> echo "test != test"
> }
>
> echo end
It's okay like that, it's like lists (&&, || chained commands) should
work. If it's not safe for you, just use an ''if'':
snipsnap
if [ "test" = "test" ]; then
false
else
echo "test != test"
fi
echo end
snipsnap
J.
Re: Comparison failure
Chet Ramey wrote: > Dave Rutherford wrote: > >> Now, "[[" isn't very well documented, so I tend not to use it, > > I'm always interested in suggestions for improving the bash documentation. > Can you tell me what's unclear about the existing description of > `[['? > > Chet > The documentation is complete. What some people always seem to forget is, that it's a reference, not a tutorial. You can't start to learn from the documentation. IMHO the job of the Bash documentation is to tell that "[[ ]]" exists, its working prionciple, and its differences to "[". But its job is not to tell *why* it exists. So, if the Bash documentation (mainly talking about the manpage here) is intended to be used as a reference, then it's definitely complete. When you know what you're searching for, you find it within a minute in 95% of the cases. J.
Re: Sub-arrays do not work with non-blank IFS
Lea Wiemann wrote:
> Repeat-By:
>
> IFS=$'\n'
> a=(A B C D)
> b=("[EMAIL PROTECTED]")
> echo "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" # 4, A B C D -- OK
> b=("[EMAIL PROTECTED]:2}")
> echo "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" # 1, C D -- bug, should be 2,
> C D
I have to correct myself, in the normal case "[EMAIL PROTECTED]:2}" will expand
indeed word-wise. So it's a bug.
Sorry,
Jan
Re: Sub-arrays do not work with non-blank IFS
Lea Wiemann wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i486
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
> -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
> -g -O2
> uname output: Linux fly 2.6.22-3-686 #1 SMP Mon Nov 12 08:32:57 UTC 2007
> i686 GNU/Linux
> Machine Type: i486-pc-linux-gnu
>
> Bash Version: 3.1
> Patch Level: 17
> Release Status: release
>
> Description:
>
> If the IFS does not contain a blank, copying an array using
> ("[EMAIL PROTECTED]") works, but creating a sub-array using
> ("[EMAIL PROTECTED]:offset:length}") does not work.
>
> Repeat-By:
>
> IFS=$'\n'
> a=(A B C D)
> b=("[EMAIL PROTECTED]")
> echo "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" # 4, A B C D -- OK
> b=("[EMAIL PROTECTED]:2}")
> echo "[EMAIL PROTECTED]", "[EMAIL PROTECTED]" # 1, C D -- bug, should be 2,
> C D
I assume:
"[EMAIL PROTECTED]" is defined (see manual) to expand as separate words.
"[EMAIL PROTECTED]:x:y}" will "just expand"
>From my understanding this is the correct behaviour.
J.
Re: `read' builtin does not take last record without trailing delimiter
Scott Mcdermott wrote: > Bash does not seem to take the last record if it has no > trailing delimiter: > > > $ echo "0 1 2^3 4 5^6 7 8" | > while read -a array -d ^ > do echo $array > done > 0 3 > This behavior is counter-intuitive. It just throws away the > last line and it's never even put into the array. I think > the whole intention of using read to split lines by > delimiter is always to read the last line even though it has > a trailing null or newline instead of a delimiter, just like > awk does. It's not 'read' directly, it's the exit code of 'read'. The value is read and the array is set correctly, it's just the trigger for the 'while' loop that's missing (because of the exit code of 'read'). > > IMO this is a bug but I'm sure this behavior is known and I > am wondering at its rationalization? I don't see any > arguments about it in the archives, this is just accepted? > It seems silly for a script to always have to take care to > add a delimiter even if the input doesn't have one, as is > extremely common (perhaps even universal). At the very > least I think an option should be present to turn on this > behavior for the builtin, because I can see some cases where > one *would* want the behavior as implemented as well. I'm sure Chet accepts patches, if he thinks it's a bug. I'm not sure if it's a bug per se, but at least it's a usability issue to discuss. Maybe it can be reduced to "read reacting on EOF" - and yes, the current behaviour of reaching EOF is documented in the manual, and personally I'm fine with it. J.
Re: Possible eval builtin speedup?
Nicolas Bonifas wrote: >> > I don't know much about bash internals, but there is probably room for >> > a huge performance improvement in speeding up the eval builtin. >> > What do you think about it? Would it be a difficult task? >> >> It is more likely to be the command substitution that is slow. > > You're right: > $ time (echo `dircolors` > /dev/null) > > real0m0.318s > user0m0.312s > sys 0m0.008s > > I ran the previous tests with bash-3.1. With bash-3.2, echo > `dircolors` take 0.088s of user time (1/4th of the time needed by > bash-3.1), and dircolors > dircolors_output && sh ./dircolors_output > still takes 0.004s, so it is more than 20 times faster than using > command substitution. > > So, do you think that speeding up command substitution would be a > difficult task? I assume you know that the speed issues most likely come from the operating system's supporting functions like the fork() and exec*() family members? Executing another process takes time and there is not much you can do about it. If you have speed problems while using a huge amount of command substitutions you either have a bad script design or use the wrong language for your specific task IMHO. J.
Re: Possible eval builtin speedup?
Nicolas Bonifas wrote: > Thanks for your answer. > >> I assume you know that the speed issues most likely come from the >> operating system's supporting functions like the fork() and exec*() >> family members? > > How does it explain the speed difference between "echo `dircolors`" > and "dircolors" ? Yea, I didn't look close enough. My fault. J.
Re: style of assignment to variable changes command selection
Bob Proulx wrote: > This implies to me that a variable assignment forces subsequent > commands to be external commands because the current environment is > not affected. In your case above the external /usr/bin/time program > is forced by the variable assignment requiring the environment > variable set for it. I think the hint is in the difference of a (grammar-)"pipeline" and a "simple command". The variable assignment to change the environment of the called program is part of the simple command. The time keyword is part of the pipeline syntax. I think the correct way to do that is: time X=x foocommand since X=x time foocommand implies that this is a simple command. Jan
Re: would you give me a hand with a simple 'if' bash script?
hawa wrote: > Execuse me, would you give me a hand with a simple 'if' bash script? > I want to make folders "00", "01",...,"20" and > copy existing files file_00, file_01,,file_20 to each folder. > Thank you very much. > > > > - > for (( i = 1 ; i <= 20; i++ )) > do > > if [ $i -gt 10 ]; then foldername = $i > filename = "file_" > filename = $filename$i > else > foldername = "0"$i ## > filename ="file_0" ## > file = $filename$i ## > fi > > done untested: for (( i = 1 ; i <= 20; i++ )) do foldername=$(printf %02d $i) filename=$(printf file_%02d $i) # now, do whatever you want with $filename # and $foldername (cp, mv, rm, ...) done J.
Re: Fwd: Problem with bash completion
Chris F.A. Johnson wrote: >> bash-3.2$ ./x/ < tab after x now adds slash >> >> Once the shell starts doing this, it keeps doing it. Restarting bash >> solves the problem. > >I don't see that problem, and I'm using the same version of >bash. I can reproduce it, so it's not just his imagination :) J.
Re: problems with 'read'ing from a pipe
John Smith wrote: > Ok, so maybe I should have just 'read the manual' > ;) > > But it still confuses me somewhat, since AT&T's kornshell behaves > differently.. I just downloaded the latest available version for Linux > from the url mentioned below, and it does work in AT&T's ksh as I > expected... > > > http://www.research.att.com/sw/download/ > > But I guess that you would consider that a bug in ksh ? > ;) KSH simply works different. I don't exactly know if it makes sense for you to transform the knowledge about technical details from on eshell to the other. J.
Re: problems with output redirection
Verena Alishahi wrote: > My first script (local.sh) reads a list of worksation cluster clients > from hosts.inp in a loop and prints some output to output.txt. In the > loop a second script (remote.sh) is called in a ssh instruction. > remote.sh then writes some output to the same output.txt file, but this > output doesn't reach the output file correctly. > > Both the bash-scripts and the output file are stored on an > NFS-Filesystem (on the workstation cluster server), so every client can > access them. I would expect this to fail anyways. Regardless if it worked before or not (I guess that was more luck). Your problem reduces (IMHO) to concurrent access to the same file without mutual exclusion. I didn't expect the glibberish to be in the file (the NULs), more that the order is puzzled, but I guess that's a consequence of the NFS stateless access method. Just my humble opinion, I'm not an expert in this. J.
Re: read builtin function keeps trailing white space
Eduardo Sanz Garcia wrote: > Description:* >read builtin function keeps trailing white space when the default > variable REPLY is used. >This is specially bad when using the -e option because readline puts > and extra space after pressing a the tab key to autocomplete a word. >The IFS that delimits a word shouldn't be assigned to the variable. > * > Repeat-By:* >Type the following: >read >type something with one trailing space >echo "|$REPLY|" >REPLY keeps the trailing white space > >Then try this other variant: >read VAR >type something with one trailing space >echo "|$VAR|" >VAR doesn't keep the trailing white space. >This last behavior is the correct because "read" should parse > everything by words (IFS are the delimiters and are not included). This behaviour is IMHO intended and documented. Using one or more variable name(s) makes read assigning "every word" to the variable(s); using no variable name (fallback to REPLY) makes it assigning "the line" (!) to REPLY. It's a bit hidden in documentation, you need to see the difference between "words" and "line" in manpage. J.
Re: function names which contain a 'dash' character
Stephane Chazelas wrote:
> Note that bash didn't have to. POSIX allows a shell to accept
> any character in a function name, but it says one shouldn't use
> those in a POSIX script, which is different.
I'm not a POSIX expert, and this is the SUS, but I read:
| The format of a function definition command is as follows:
| fname() compound-command[io-redirect ...]
| The function is named fname; the application shall ensure that it is a
| name (see the Base Definitions volume of IEEE Std 1003.1-2001, Section
| 3.230, Name).
--> ("name" def)
| In the shell command language, a word consisting solely of
| underscores, digits, and alphabetics from the portable character set.
| The first character of a name is not a digit.
just my2ct,
Jan
Re: function names which contain a 'dash' character
Paul Jarc wrote: >> | The function is named fname; the application shall ensure that it is a >> | name (see the Base Definitions volume of IEEE Std 1003.1-2001, Section >> | 3.230, Name). > > "The application" is the script, not the shell, so this is consistent > with Stephane's statement. Ok, got it - makes far more sense now! Thanks, Jan
Re: unexpected behavior of 'read' builtin
Juliano F. Ravasi wrote: > The second one is that it chops leading and trailing whitespace > when you provide one variable for assignment, and not when you > use the default $REPLY. > > I don't know if these are intended behavior, but it doesn't seem > to be documented, leading to a surprise when you expect > something and get some other thing instead. > > Repeat-By: > > [...] > > About trailing and leading whitespace: > > ~$ read <<< ' a b '; declare -p REPLY > declare -- REPLY=" a b " > > ~$ read VAR <<< ' a b '; declare -p VAR > declare -- VAR="a b" > > Note how whitespace is removed when using $VAR, but not when > using $REPLY. IMO the key for that behaviour is already in the docs: "...with leftover words and their intervening separators assigned to the last name." (read with variable name supplied) and here: "If no names are supplied, the line read is assigned to the variable REPLY." The difference I see is: - with variable name supplied, it's split into words and leftover words are stored with their intervening separators into the last variable given. Since there is only one variable, the effect is what you see. - without any variable name supplied (default: REPLY), the line (!) is stored. J.
Function definition syntax inconsistencies
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux mainserver 2.6.18-6-486 #1 Sat May 24 09:50:27 UTC 2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: The function definition is allowed in 3 forms: 1. NAME() ... 2. function NAME() ... 3. function NAME ... The 3rd form can't be used when specifying an explicit subshell as body. I don't have a non-Debian system at hand to test it but I don't think Debian patches are applies in this area. Also I don't have a higher Patchlevel here to test, sorry. Repeat-By: Definition of the following functions works: - somename() (echo) - function somename() (echo) This definition fails: - function somename (echo) Fix: No fix, just a guess: It might be the code or part that parses/awaits the optional "()". -- This is my life - this is my net! - Jan
Re: Function definition syntax inconsistencies
Thanks for your replies. I didn't want to raise a portability and POSIX discussion. I know about that. I was referring to either a bug in the Bash manual or a bug in the Bash code, nothing else. Let's try to rephrase that a bit (the topic is not POSIX nor portability): The Bash manual allows the syntax of the function definition as follows: - [ function ] name () compound-command [redirection] This defines a function named name. The reserved word function is optional. If the function reserved word is supplied, the parentheses are optional. [...] - That means for me, extracted, I have the following options: 1. name () 2. function name () 3. function name They all work fine, EXCEPT: When you use the third form shown above and use the subshell-grouping compound command '(...)' as function body, then it doesn't pass the parser: - $ function name (echo) bash: syntax error near unexpected token `echo' - That's the reason I think there's a bug, either in the description or in the code. Since the rest of the behaviour of function definitions is very consistent as described in the manual, I assume it's a bug in the code. That's all about this bugreport, it wasn't about Bash allowing/not allowing any standard/nonstandard features, it simply was about Bash not being consistent in this one case. J.
Re: range match works incorrect
Roman Rakus wrote: > I think in range [a-d] shouldn't be any upper char. These are 2 > different things. Collate orders and range match. Try to use glob and > you will see difference. > This is really not good behavior of bash. This is and always has been locale-dependent. The collation sequence defined with the left and right borders you give with [x-y] matters. It's the very same behaviour you have with BRE/ERE. Not to mention the POSIX requirement. J.
Re: range match works incorrect
Roman Rakus wrote: > sequence, inclusive. In other locales, a range expression has > unspecified behavior: strictly conforming applications shall not rely on > whether the range expression is valid, or on the set of collating > elements matched. A range expression shall be expressed as the starting > point and the ending point separated by a hyphen ( '-' ). > > > So if I understand it well, the behavior of bash isn't bad. But there is > question, if this behavior we would like to change or not? I think more > predictable is glob()-like behavior then strcoll(). Okay, I have to say sorry, I didn't see that exception about the behaviour in non_POSIX locales. I think the rationale about it is worth to read: http://www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap09.html (scroll down to "RE Bracket Expression") IMHO this exception has clear historical reasons. J.
Re: Function definition syntax inconsistencies
Chet Ramey wrote:
>> -
>> $ function name (echo)
>> bash: syntax error near unexpected token `echo'
>> -
> It's not. It's a shift/reduce conflict in the grammar. The default
> yacc/bison behavior is to choose the `function word () command' production,
> and I have left it that way. The `function word command' form came from
> ksh, which doesn't allow the construct you used anyway (it requires one
> or more newlines after the word), so the current bash implementation
> supports all existing ksh uses.
Okay, then it could be mentioned in the manual (as exception or so, like
the semikolon in {...;} "for parsing reasons"). Some beginner pointed me
at this, thinking he made a mistake or didn't understand the manual.
Sorry for not providing a manpage patch.
--
This is my life - this is my net!
- Jan
Re: Bash/readline enhancement: wish to pre-set initial value of input text
Richard Neill wrote: > Dear All, > > When using read, it would be really neat to be able to pre-fill the form > with a default (or previous) value. > > For example, a script which wants you to enter your name, and thinks > that my name is Richard, but that I might want to correct it. > Alternatively, this would be useful within a loop, to allow correction > of previously-entered text, without fully typing it again. A bit of the functionality (in some way) is already there. You can preload the commandline history and use read -e: --snipsnap-- If -e is supplied and the shell is interactive, readline is used to obtain the line. --snipsnap-- A bit of hard work, though. J.
Re: Bash substrings: wish for support for negative length (read till n from end)
Richard Neill wrote:
> $ echo ${stringZ:2: -1} #Wish: start at 2, read till
> ERROR #1 before the end. i.e.
> # cde
>
> $ echo ${stringZ: -3: -1} #Wish: start 3 back, read till
> ERROR #1 before the end. i.e.
Use (-1), i.e.
$ echo ${stringZ:2:(-1)}
See also
http://bash-hackers.org/wiki/doku.php/syntax/pe#substring_expansion (at
bottom of the section).
J.
Re: Bash substrings: wish for support for negative length (read till n from end)
Jan Schampera wrote:
> Richard Neill wrote:
>
>> $ echo ${stringZ:2: -1} #Wish: start at 2, read till
>> ERROR#1 before the end. i.e.
>> # cde
>>
>> $ echo ${stringZ: -3: -1}#Wish: start 3 back, read till
>> ERROR#1 before the end. i.e.
>
> Use (-1), i.e.
>
> $ echo ${stringZ:2:(-1)}
>
> See also
> http://bash-hackers.org/wiki/doku.php/syntax/pe#substring_expansion (at
> bottom of the section).
>
> J.
My bad - it's too early in the morning - forget about that :)
I didn't read carefully.
J.
Re: function name bug ?
christophe malvasio wrote:
cbz (){ echo "why 'cbz' not a valid function name ?";}
bash: syntax error near unexpected token `('
It works for me. What does "alias cbz" say for you?
alias work
He wants to know if you probably have an alias named "cbz" defined, not
if your alias engine works.
J.
Re: set -x output of test operator is irretating
Bob Proulx wrote: Chet Ramey wrote: Toralf Förster wrote: I'm wondering why in the example (see below) the right side is prefixed with a '\' wheras the left side is unchanged. ... [EMAIL PROTECTED] ~ $ echo "1 2 3 4" | while read a b c d; do [[ "$a" = "$b" || "$a" = "$c" || "$a" = "$d" ]] && echo oops; done + read a b c d + echo '1 2 3 4' + [[ 1 = \2 ]] + [[ 1 = \3 ]] + [[ 1 = \4 ]] Because the ==/!=/= operators are defined to match the rhs as a pattern unless it's quoted. You quoted the original string, and the `set -x' output is supposed to be re-usable as input, so the trace output is quoted appropriately. Of course that makes sense for the "==" and "!=" cases. But is that true even for the "=" case? For the "=" case I thought it was "STRING1 = STRING2" and not "STRING = PATTERN". "When the == and != operators are used, the string to the right of the operator is considered a pattern [...]" From the description for [[ ]]. = and == should make have difference in behaviour. J.
Re: set -x output of test operator is irretating
Jan Schampera wrote: = and == should make have difference in behaviour. "should not show differences" *suh* Sorry J.
Re: Last modified files with owner / time / permissions
lexton wrote:
From what I read it is not good to use ls -la in the manner I use below.
Could I run this by just using the find command with additional arguments?
I still need to be able to print everything that the ls -la command gives me
GNU find has an -ls option IIRC, which produces output similar to ls -l.
If that's not the case, you can always find ... -exec ls -ld {} \; or so.
J.
Re: Bash prints syntax error when command in $(...) contains case-esac
Juergen Gohlke wrote: Description: If a command in $(...) contains a case-esac construction, the bash prints a syntax error instead of executing the code: bash: syntax error near unexpected token `;;' In case you have trouble with code you need, use this workaround: x=$(a=4; case $a in (3) echo a=3;; (4) echo a=4;; esac) And yes, I've also seen this before and I thought it was fixed - maybe I thought of something else. J.
Re: feature request: "wait --free-slot" for poor man's parallelization
Mike Coleman wrote: Here's a bash feature I'd love to see, but don't have time to implement myself: a "--free-slot" flag to 'wait' that will wait until there is at least one free "slot" available, where a slot is basically a CPU core. Example usage: $ for ((n=0; n<100; n++)); do my_experiment $n > $n.out & wait --free-slot 4 done which I would run on a quad-CPU host. The meaning of the wait is: if I already have four background invocations of "my_experiment" running, wait until one finishes, then proceed. (If there are fewer than four running, proceed immediately.) This provides a nice sloppy way of letting me parallelize in a script without having to complicate things. "make -j" and "xargs -P" provide some of this capability, but are a lot more work to set up--I'd really like to have this at my fingertips for interactive stuff. I did something like that as a script, using an array of PIDs and a big loop and so on. I don't think it needs to be part of internal Bash features, it wasn't that much work. J.
Development snapshot
Hello, is there something like a development snapshot for Bash 4 or is the code "hidden" during development phase and I need to wait for the first release? Thanks in advance, Jan -- This is my life - this is my net! - Jan
Re: Question on bash clearwildcards
grendelos wrote: > So this is really bugging me. Why is [a-z] not case sensitive, but [A-Z] is? > For example: > > # ls -l > total 0 > -rw-r--r-- 1 root root 0 Nov 20 12:22 xa > -rw-r--r-- 1 root root 0 Nov 20 12:22 xA > > # ls -l x[a-z] > -rw-r--r-- 1 root root 0 Nov 20 12:22 xa > -rw-r--r-- 1 root root 0 Nov 20 12:22 xA > > # ls -l x[A-Z] > -rw-r--r-- 1 root root 0 Nov 20 12:22 xA > > Any ideas? > > grendelos This all depends on locales. It's useless to assume that "A-Z" or "a-z" is something about the case. See that sequence: AaBbCcDdZz Now think what "from A to Z" means here. It's all those letters except "z". Another sequence: ABCD...abcd... Here, "from A to Z" means what you *think* it always means. Consider to use [[:aplha:]], [[:upper:]] and [[:lower:]] if possible. J.
Re: [bash-testers] Re: case modification operators misbehaviour?
Chet Ramey wrote:
>> The case modification operators (for parameter expansion) seem to be
>> puzzled.
>>
>> Two things I don't understand:
>> - it seems to work word-wise (might be due to my misinterpretion of the
>> default pattern)
>
> It does work word-by-word, like the emacs-mode editing commands. I
> would like feedback on whether or not that works better than the
> alternative.
Intuitively I expected it to operate on the whole content, not word by
word. On the other hand, I have no big clue about emacs and the Bash
emacs-mode, so other people might expect it to work like that.
It doesn't really matter for scripting, because either behaviour can be
used to simulate the other (using a loop etc..).
IMHO the technical more intuitive version (working on the whole content
rather than splitting it into words) should be used. There will be less
surprises for the scripters and less surprises when using fancy
patterns. Also, when it works word by word, it should be 1000% clear
what's treated as a word separator. It took me some time to get it,
because I first experimented with PATH :) Moreover, word separators
might depend on the locale which will have typical locale effects, too.
Again, I think the basic way of seeing the content as a whole is the
clean and straightforward way for the implementation of such an operator.
Much text, but you asked for feedback ;)
I have another one, maybe my misinterpretion or an unclean documentation:
$ TEXT="Test"
$ echo ${TEXT^s}
Test
I expected "TeSt", since the pattern is "s", and the 3rd letter in
"Test" matches that, and should be changed. Interesting that it works
with ^^s (for "Tesst" then), but for all "s", of course.
It tastes like a bug or a wanted, but non-intuitive implementation.
The vice versa case ("tESST" and ,S) behaves analog.
--
This is my life - this is my net!
- Jan
Bash 4: command_not_found_handle event handler
Hello list! Just a few thoughts, awaiting comments. Currently, Bash 4 calls a fixed named function command_not_found_handle() when a command is not found. The basic approach (to have such a possibility) is great, but: I can imagine that there may be more internal events to react on in future. IMHO a more straight forward approach would be to define handlers for named events, similar like you define handlers for signals with 'trap'. Infact, 'trap' already is able to define event handlers, for example EXIT or DEBUG, which aren't signals. The purpose? When - in future - more events should be handled, the current approach ends up in an unsorted and mixed list of handler function names. A common approach for handling internal events would be better. I basically see 3 ways: - extend the 'trap' command to be able to setup (more) event handlers - make up a new command to setup event handlers - (from Plan 9 rc shell signal handling, hehe) define a namespace for function names (e.g. "event_"). An event handler for the event FOO will be called when it exists, here for example event_FOO() Opinions? Is this point of view completely stupid or is it needed? J.
Re: simple bug/compat question
Linda Walsh wrote: > Am running an older bash version and this may be fixed (assuming it > is a bug and I'm not confused...:-)) > > bash version = 3.2.39(20) > > This works: > 1)if [ -n "" -a 2 -gt 1 ] ; then echo one;fi > > This does not: > 2)if [[ -n "" -a 2 -gt 1 ]] ; then echo one;fi > > > > Shouldn't 2 work equally well as 1? > > (original test on "$1": > -n "$1" -a "$1" -gt 0 > ) I don't know if it should be line that, but it definitely isn't the case. This is also (indirectly) described in the manual: There's a section about "conditional expressions" which holds all the stuff that [ and [[ have in common, then there are individual sections for [[ and test ([) which list &&/|| for [[ and -a/-o for test. http://bash-hackers.org/wiki/doku.php/syntax/ccmd/conditional_expression /- Do not use the test-typical operators -a and -o for AND and OR, they are not known to the conditional expression. Instead, use the operators && and ||. \- Ragards, Jan -- This is my life - this is my net! - Jan
Re: Bash 4: command_not_found_handle event handler
Jan Schampera wrote: > Hello list! > > Just a few thoughts, awaiting comments. Heh. I wanted to raise a discussion about that issue, but it seems I failed (or I'm the only one who cares) ;) Jan
The colon
Hi. In comp.unix.shell [1] somebody wondered about IFS=: read a b <<< a:b; echo "'$a' '$b'" ending up in 'a b' '' Korn and Z seem to behave different. I see that across all my available Bash versions. I remember the colon to be special in some way (was it hostnames in a file path?), but I don't know. If this is intended behaviour, can you tell me why (it's gone with quoting/escaping, of course)? J. [1]
Re: The colon
Stephane Chazelas wrote: >> If this is intended behaviour, can you tell me why (it's gone with >> quoting/escaping, of course)? > [...] > > That would be a bug. Looking at the code, it takes a different Good to know that I'm not completely mistaken - it smells buggy. Only Chet knows for sure why it was hacked, I guess. J.
Re: if, -n
coubeatczech wrote: > c...@notas:~$ if [ -z $variable ]; then echo true; fi > true > c...@notas:~$ > > Can anybody explain to me this behaviour? I would expect not any output in > the last command...? The variable is set to zero and there is the condition > is still true...? http://bash-hackers.org/wiki/doku.php/commands/classictest#number_of_arguments_rules You'd need some quoting. Jan aka TheBonsai
Re: Bash with colors?
tal396 wrote: > there is any way to echo "aaa" or any msg in colors? Start at http://bash-hackers.org/wiki/doku.php/scripting/terminalcodes and continue at whatever Google spits out for: - bash colors - terminal colors - ANSI colors - VT100 colors J.
Re: Help: Bash script that show you the last file created?
Mike Frysinger wrote: >> there is any way to get the last file that created that is fomat is *.sql > why not just use `ls` and one of its sort options ? the ls man page > documents > how to sort by creation time > -mike Without looking there: It can't be documented, because there's no general way to retrieve the creation time of a file. J.
Re: Help: Bash script that show you the last file created?
Mike Frysinger wrote: >> Without looking there: It can't be documented, because there's no >> general way to retrieve the creation time of a file. > > the op wasnt asking for the time, they were asking for the last created file. > > and the ls man page talks how to sort by ctime. Yes, that's the issue. ctime is not creation time. There is no standard timestamp for "file creation". This doesn't exist. Ergo: No way to sort by creation time. J.
Re: Bash with colors?
Antonio Macchi wrote: > commands like "ls --color" does not use terminfo capabilities... > > ...use instead fixed strings (without regards about TERMinal) > is this a good (and safe) choice too? IMHO not. Too many assumptions. GNU ls seems to always assume an ANSI terminal, regardless which TERM is set. Or did I miss something? J.
Re: Bash with colors?
Antonio Macchi wrote: >>> commands like "ls --color" does not use terminfo capabilities... >> >>> ...use instead fixed strings (without regards about TERMinal) >>> is this a good (and safe) choice too? >> >> IMHO not. Too many assumptions. GNU ls seems to always assume an ANSI >> terminal, regardless which TERM is set. Or did I miss something? > I have done a little search about how terminals uses "setaf" > a very very long list of terminals uses the same style of capabilities > are maybe the others simply "out-of-date"? No wonder, 'setaf' is "set ANSI foreground" IIRC, dedicated to ANSI terminal control. But yes, you're right, most terminals talk ANSI, at least for the most important codes. And for the same reason some people hardcode the dot or the comma as thousands separator in their code, ignoring locale settings. "Never seen something different." Alone the fact that STDOUT is a terminal, without knowing which terminal it is, isn't a good base for a decision what to send. I remember alot of stupid MS-DOS applications that blindly relied on running ANSI.SYS CON driver - producing screen output that looked like streusel slices. Just my 2ct J.
Re: coproc command doesn't accept NAME arg
Tim Hatch wrote: > Pilot:~/tmp/bash-4.0 tim$ coproc NAME ls > [1] 18474 > Pilot:~/tmp/bash-4.0 tim$ ./bash: line 32: NAME: command not found > > [1]+ Exit 127coproc COPROC NAME ls For some reason it expects a compound command on named coprocesses, http://bash-hackers.org/wiki/doku.php/syntax/keywords/coproc MSGID bash(1): If NAME is not supplied, the default name is COPROC. NAME must not be supplied if command is a simple command (see above); otherwise, it is interpreted as the first word of the simple command. Yes, it's not intuitive. Jan
Re: large exit values (>255)
Mike Frysinger wrote: > $ true > $ echo ' > > $ echo $? > 258 > > $ true > $ echo ' > > $ echo ' > > $ echo $? > 386 > > that doesnt seem right to me :) > > the first test seems fine, and older versions of bash would set 258 for the > second test (not sure if it's correct though), but the third test looks like > a > regression (not clearing exit status completely somewhere ?). > -mike Wow - how does one find that out? ;) IMHO everything above 255 is wrong. Maybe it could be "fixed" by making the $? expansion only respect the lower 8 bits. Though...weird :) (works in Bash 3 and 4 here) J.
Re: large exit values (>255)
Mike Frysinger wrote: > $ true > $ echo ' > > $ echo $? > 258 > > $ true > $ echo ' > > $ echo ' > > $ echo $? > 386 Just tested it, hopefully it's as easy as changing every itos (last_command_exit_value) to itos (last_command_exit_value & 0xFF) in subst.c (seems 2 times). I don't provide a patch because it was a quick look and I don't know if any other parts of the code are involved (if yes, the patch would be awfully wrong). J.
Re: arguments to script prefixed with "--" in debug
lehe wrote: > Hi, > I am trying to debug my shell script by bashdb. My script take as argument > "--gdb", so I wrote > bashdb myscript.sh --gdb > However, this way it will produce error that bashdb: > unrecognized option '--gdb' > > If I quote --gdb as > bashdb myscript.sh '--gdb' > then I will end up with the quotes as part of my argument. > > How could I fix this problem? Thanks! I may be wrong (I son't have bashdb...), but what about good old bashdb -- myscript --gdb J.
Re: reference dir ../common in script
OnTheEdge wrote:
> I'm trying to check for a directory and create it if it doesn't exist as
> follows:
>
> CommonDir="../common"
> if [ -d ${CommonDir} ]; then
>mkdir "${CommonDir}"
> fi
>
> It works from the command line, but my script doesn't seem to like it and I
> can't figure it out.
>
> Thanks for any help,
> Duane
You have a wrong logic. This script will mkdir if it exists.
use
[ ! -d "${CommonDir}" ]
J.
Re: Feature Idea: Enhanced Tab Completion
Cam Cope wrote: > Combine tab completion with history: when you put ! at the beginning of a > command and use tab completion, it displays history results IMHO yet a new history expansion/editing/searching mechanism (there already are a few) would bloat it even more. But that's just my opinion. J.
Re: contents of whole arrays dissapears leaving while read loop
Lennart Schultz wrote: > In the construct > cat file|while read line > do > done > the content of any arry assignments in the loop dissapears leaving the loop: This is logic, since every part of the pipe runs in an own subshell (the first one runs in the "current shell"). This behaviour is also *not* limited to arrays. This is not a bug, this is a consequence of Bash's design. You might find hints here: Why? http://bash-hackers.org/wiki/doku.php/scripting/processtree How to do it instead? http://bash-hackers.org/wiki/doku.php/syntax/expansion/proc_subst J.
Re: [bash-bug] contents of whole arrays dissapears leaving while read loop
Dr. Werner Fink wrote: >> This is not a bug, this is a consequence of Bash's design. > > Yep ... nevertheless a side mark: ksh can do ;) Which is: A consequence of Korn's design ;-) *waves the 80km to Nuremberg* Jan
Re: arithmetic + > + subshell might not be documented
jida...@jidanni.org wrote: > Might not be documented: > > $ cat q > for i in : :; do :|: > x$((++a)); echo =$a=; done; ls x?; rm x? > for i in : :; do : > x$((++b)); echo =$b=; done; ls x?; rm x? > $ bash q > == > == > x1 > =1= > =2= > x1 x2 > > I don't think it's specific to arithmetics. I rather think the redirection (since it's part of the simple command, not the pipeline) happens in the subshell. The side effects affect the arithmetics, of course. J. PS: I don't know if that's worth to document, I would have epxected that behaviour. But I may be wrong anyways.
