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
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
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 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
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
Cu
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.
E
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
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 reall
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
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 r
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
shoul
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
me
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
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,
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
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
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 i
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
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 m
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 filed
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 ma
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 desig
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
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 var
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
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 y
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
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 d
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
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...@u
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 kno
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
Sascha Ziemann wrote:
The following code prints "a". The second false terminates the script
but the first does not.
set -e
declare a="a"$(false)
echo $a
b="b"$(false)
echo $b
The first operation succeeds, the second doesn't.
The first operation
Krzysztof Zelechowski wrote:
Description:
The text of pwd and the value of $PWD return a cached value, regardless
of the actual current path.
Repeat-By:
mkdir '-p' 'a' && cd 'a' && mv '../a' '../b' && enable '-n' 'pwd' && builtin
'pwd' && pwd
Fix:
cd '-P' '.'
I thi
I'm sorry to not answer a message directly, but I didn't get the mails
of this list during the last day - no idea why. Quoting text from the
pipermail archive.
>> After initialÄy introducing =~, Chet made it consistent with =/==
>> in a second version, means: =/== doesn't do pattern matching f
Linda Walsh wrote:
Why do (or should) double quotes lose their normal meaning inside
double brackets?
After initialĺy introducing =~, Chet made it consistent with =/== in a
second version, means: =/== doesn't do pattern matching for parts inside
quotes, =~ doesn't du regexp matching for part
Mike Frysinger wrote:
On Wednesday, August 25, 2010 00:59:58 Jan Schampera wrote:
Mike Frysinger wrote:
the difference here being the value in variable "a" after function "f"
finishes executing. i was expecting the behavior of `bash`, not of `sh`.
i cant seem to find an
Mike Frysinger wrote:
the difference here being the value in variable "a" after function "f"
finishes executing. i was expecting the behavior of `bash`, not of `sh`. i
cant seem to find anything covering this in the man page except for perhaps
interpreting the meaning of some sections to mea
Jan Schampera wrote:
1) Why doesn't this print anything
while read -d'' -n1 ch; do
echo "$ch"
done <<< $'hello\nworld'
2) Why does this print something, but only up to the hyphen?
while read -d'' -n1 ch; do
echo "$ch"
don
Hello,
don't ask about the detail how I originally invented this code, but I
stepped over something I really can't explain:
1) Why doesn't this print anything
while read -d'' -n1 ch; do
echo "$ch"
done <<< $'hello\nworld'
2) Why does this print something, but only up to the hyphen?
whil
Linda Walsh wrote:
On 8/2/2010 1:13 PM, Chet Ramey wrote:
There are several versions of `autoload' in examples/functions.
Chet
===
I've been using 'man bash' as my reference. I don't see a reference
to examples or autoload, and finding 'functions' doesn't show me any examples.
Is the
Linda Walsh wrote:
The curly brackets are suposed to be optional.
They are line "2" of the Compound commands list below...
Don't ask me why, but it works when you don't use the "function"
keyword, but "()" instead:
foo() [[ 1 ]]
Might be a parsing bug, though you shouldn't use "function" at
Hello,
Tested versions:
- 4.1.2(1)-release
- 3.2.39(1)-release
Reproduce by:
string="1/2 3="
echo ${string//[= /]}
Expected result:
123
Actual result:
1/2 3=
Workaround: Escape the "inner" slash with a backslash.
Within a bracket expression, the slash should lose its special meaning
Clark J. Wang wrote:
Running a cmd in background (by &) would not create subshell. Simple
testing:
#!/bin/bash
function foo()
{
echo $$
}
echo $$
foo &
### END OF SCRIPT ###
The 2 $$s output the same.
This doesn't mean that it doesn't create a subshell. It creates one,
since it can't
Chris F.A. Johnson wrote:
$$ refers to the subshell.
There's no subshell here, I think.
The background process invoked by &.
$$ is meant to always report the "main shell", I'd guess this is true
for this case, too.
J.
Linda Walsh wrote:
I suppose I'm presuming these features are not already implemented in
some fashion -- did I overlook them, or would they be 'new'?
I know it's not applicable for all cases, but I usually use read to
split strings into variables/an array.
J.
RESEND FOR THE MAILINGLIST
Britton Kerin schrieb:
Which in a pipeline is supposed to be the output of the previous command, right?
Its not at all obvious to me why it behaves as it does.
The other subthread of this thread is about it: In Bash, all parts of a
pipeline are executed in an own su
Dr. Werner Fink wrote:
The question rises: Why does the bash require a sub peocess/shell
for the final command of a pipe sequence.
I'd think this is more or less a design choice at first (with one or the
other issue, maybe for both solutions - though I can't construct a
failing case for the
Britton Kerin wrote:
How so? It seems that read always reads from the terminal even when its in a
shell pipeline.
This isn't correct. Read reads from STDIN by default.
Regards,
Jan
Marc Herbert schrieb:
From section 2.12 and from messages posted here in the past I
understand that POSIX allows either one. This ambiguity reinforces the
need for documentation IMHO.
I agree with Greg here, it's a well known "don't". What should be
documented is (maybe it is?) how pipelines
Oh, and to be complete:
uname -rms yields:
* Linux 2.6.26-2-amd64 x86_64
The C library is a:
* GNU libc 2.16.6-3
The crashed Bash is a:
* ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
Jan "TheBonsai"
Chet Ramey wrote:
How about a stack traceback?
I'm so sorry, I thought this was clear and easy to reproduce/verify.
I'm using this to generate the script. The number of commands varies
between shell versions (and likely other platform stuff), so you might
need to play around with the values
Jan Schampera schrieb:
The result of these tests was a SEGV (after some 78K line length).
Shouldn't this be sanely catched somehow by the parser? I didn't look
deeper, but it looks like a blindly filled buffer or something like that.
Sorry, I should make clear that the test case w
Hello list,
somebody in chat just asked about the maximum input line length, I know
(and told him) that this might be very platform dependent, but I did
some tests.
The result of these tests was a SEGV (after some 78K line length).
Shouldn't this be sanely catched somehow by the parser? I di
Bernd Eggink wrote:
Select lists are sometimes displayed with incorrect vertical alignment
if an item contains one or more German umlauts. Examples:
select x in äöü blah{1..20}; do :; done# wrong
select x in amöbe blah{1..20}; do :; done# wrong
select x in amöb blah{1..
Hello Chet,
hello list,
during some discussion in the IRC #bash channel on freenode we found a
weird behaviour of the 'hash' builtin command.
The command exits true if the operand in question contains a /, no
matter if that makes sense or not:
---
$ hash
'CHANGELOG_CURRENT="http://slackwa
Clark J. Wang schrieb:
> And if the script crashes the dir will be left unlocked.
System crashes and kill -9 are the problem. The rest is none.
If the area isn't too complex, noclobbered redirection serves well. But
if you have other options, they should be used, of course.
(doing this on a clu
Clark J. Wang schrieb:
> In C code I can use lockf(), flock(), semaphore and mutex for locking /
> unlocking. Can bash provide some similar mechanisms?
>
For simple things, which don't need to be 1000% rocksolid, you can use
atomic operations like mkdir or noclobbered redirection for mutex purpos
Clark J. Wang schrieb:
> I saw a printf usage from a Linux forum's post:
>
> # printf "%d\n" "'a"
> 97
> #
>
> It's really cool but I found no info in bash's manual. Are there any other
> undocumented interesting features? :)
>
I "documented" it, though I don't remember where I first heard abou
Vadym Chepkov schrieb:
> I would expect never see "Continue" printed
The 'exit' command exits the subshell you just created.
http://bash-hackers.org/wiki/doku.php/scripting/processtree
There's also a FAQ about it, E4.
Jan
Chet Ramey schrieb:
> This was reported about five weeks ago, and there's a patch in the pipeline.
> I've attached a version for the curious; try it out and let me know.
Ah, I had a feeling I alredy read about it somwhere, but I didn't find
it quickly, so I thought I was wrong.
Thanks,
Jan
Hello list,
hello Chet.
Bug reported on freenode's IRC #bash by: Satgi
There is a crash somewhere in completion (the last commandline is
completed using TAB):
echo $BASH_VERSION
4.1.2(1)-release
mkdir -p the/?/directory
./the/\?/Segmentation fault (core dumped)
These completions DO NOT
Mike Frysinger schrieb:
>> When using the bash shell in an xterm or rxvt terminals at least,
>> commands executed which start with a space, eg " ls" are not added to
>> the command line history and so are not accessible by ctrl-p.
>
> this is by design
> -mike
This is controlled by the HISTCONTR
Andreas Schwab schrieb:
>> It's a character like 'A' or 'B'.
>
> 'A' and 'B' are letters, $'\r' is whitespace.
Yes... :)
Evan Driscoll schrieb:
> Then, many programs don't handle them per se, but *not* handling them
> doesn't cause much problem. grep, cat, and echo probably fall in this
> category.
Bash doesn't handle it. It's a character like 'A' or 'B'. It causes
problems :)
J.
Evan Driscoll schrieb:
> echo a
> echo b
> seemed to work with both CRLF and LF endings. However, further
> experimentation confirmed what you probably already know, which is that
> it only appeared to work; in fact what was happening is that the CR
> character was being passed to echo as part
drisc...@cs.wisc.edu schrieb:
> Some of the time, using CRLF line endings cause syntax errors
> in Bash scripts ("unexpected end of file").
>
> This problem shows up on Bash 4.1 on Linux, Bash 3.2 on Linux,
> and Bash 3.2 on Cygwin (where I first noticed it).
Normal. Thou
Jon_R schrieb:
> http://old.nabble.com/file/p27316649/newsh2.sh newsh2.sh
You have a misunderstanding about select here, I guess.
Select is supposed to display a list of given words and take user input
(index to these words). It more or less is the same as a for loop, it
just doesn't iterate th
Leonid Evdokimov schrieb:
> This problem may be fixed if bash does not optimise number of getcwd() calls,
> but I'm not sure if the bug is really a _bug_, but not a sort of strange
> feature.
Sorry, I didn't read carefully enough :)
J.
Leonid Evdokimov schrieb:
> This problem may be fixed if bash does not optimise number of getcwd() calls,
> but I'm not sure if the bug is really a _bug_, but not a sort of strange
> feature.
Depends what 'bar' is above, assuming it's a (sym-)link or a bind here:
IMHO this is not a bug. There sim
Ken Irving schrieb:
> That's up to that function to determine, since bash passes control over
> to it. It should be able to handle whatever it gets. My use case is
> to take things that look like 'object.method' -- which are not likely
> to collide with normal executables -- and run them under a
Ken Irving schrieb:
>> This patch is not sufficient, as it leaves the error message, but it
>> does call the hook function in the problem cases:
I'm just not sure if it makes sense. I mean, if the user requests the
execution of a *specific file*, what should the hook function do if it
fai
Ken Irving schrieb:
> Description:
> I'm not sure this is a bug, but I notice that the
> command_not_found_handle function is not called if the "command" has a
> slash in it. I can't find anywhere in the bash source producing the
> "No such file ..." error message, so I guess thi
Mun schrieb:
> nounset on
Something sets -u in your startup scripts (or in the script or whatever)
jida...@jidanni.org schrieb:
> OK, never mind. Market demand too low to add...
I rather think you could just define a stop()
Lhunath (Maarten B.) schrieb:
> My bad. I was under the impression `read` was a Bourne shell-only
thing and not standardized under POSIX.
(not personal for you only, I see that very often)
It would be nice if people actually read POSIX before they talk about it.
Jan
Antonio Macchi schrieb:
> $ hd <(echo -en \\0{0..3}{0..7}{0..7})
>
>
> it breaks the console.
>
>
It doesn't "break the console", it crashes the shell (here with a
subshell to get the text):
bon...@core:~$ bash
bon...@core:~$ hd <(echo -en \\0{0..3}{0..7}{0..7})
malloc: ../bash/subst.c:419
Just for completeness: Same with 3.2.39, 4.1 alpha and beta.
Jan
Chet Ramey schrieb:
> That's how I prefer it. I don't do public development on savannah, and
> I do controlled test releases.
The official patches should be there as individual commits. Though, I
admit it's not a small amount of work to do all that for the past
releases. Such a GIT or SVN reposi
Antonio Macchi schrieb:
> what's the rasonable limit in using this "compact" contruct, after which
> the for (( i=0; i<1000...; i++ )) became better?
Hardware/OS limits.
J.
Chet Ramey schrieb:
>> Code:
>> $ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo
>> "Exists"
>>
>> Output:
>> Doesn't exist
>> Exists
> Please read the Bash FAQ, question E1. The behavior of test depends on
> the number of arguments; the rules are in the manual page.
>
>
Chet Ramey schrieb:
> redirect stderr
> kill pid
> wait pid
> restore stderr
>
> It seems to me that this sequence forces the necessary synchronicity.
Interesting. And sad that I never thought of that.
Jan
Hello list,
Code:
$ [ ! -e /bin/bash ] && echo "Doesn't exist"; [ -e /bin/bash ] && echo
"Exists"
Output:
Exists
Code:
$ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo
"Exists"
Output:
Doesn't exist
Exists
It seems there's a difference between -a and -e, though they are
Ciprian Dorin, Craciun schrieb:
> Thus if I say: `set -e ; { false ; true ; }` it works, but when I
> put the `||`, it doesn't...
I think it's because { ...; } isn't a simple command (however, its
components are).
J.
Jeff Chua schrieb:
> The man page mentioned that 'set -m' should print 'a line containing
> their status upon their completion' ... which should imply 'set +m'
> should NOT print the status.
>
> Attached is a patch to 'silent' bash so that it won't print the status
> when 'Monitor mode' is off (s
Good morning,
http://www.gnu.org/software/bash/manual/bashref.html#Brace-Expansion
The brace expansion increment syntax is shown wrong.
OLD:
A sequence expression takes the form {x..y[incr]}, where x and y are
either integers or single characters, and incr, an optional increment,
is an integer.
Jo King schrieb:
> Fix:
> [ bash/the read code could
> detect there's no stdin and sleep for 1-2 seconds]
If you consider this as a bug, the bug is not in Bash (but in the
application).
In short you request that read should wait a second, once it got a
end-of-file signalled, I don't think
Marc Herbert schrieb:
>> Repeat-By:
>> $ unset PWD
>
> Fix = readonly PWD ?
This is not a fix, this is a workaround.
Anyways, I can't reproduce it.
J.
Jan Schampera schrieb:
It was a "fresh" install. Unpacking source + applying pathces, then
build *scratches beard*.
And it was done without bison - my bad. Works now.
Jan
Andreas Schwab schrieb:
Jan Schampera writes:
I can reproduce it. What can I do to help tracking it down?
Make sure the parser was regenerated after applying patch 1.
It was a "fresh" install. Unpacking source + applying pathces, then
build *scratches beard*.
Jan aka TheBonsai
Hey Chet,
I can reproduce it. What can I do to help tracking it down?
bon...@core:~/devel/bash-4.0$ ./bash -c 'echo $(echo \|)'
./bash: command substitution: line 1: syntax error near unexpected token `)'
./bash: command substitution: line 1: `echo \|)'
bon...@core:~/devel/bash-4.0$ ./bash -c 'e
Mitch Frazier wrote:
> The close appears to be a special case of (from the man page):
>
>> Similarly, the redirection operator
>>
>> [n]>&digit-
>>
>> moves the file descriptor digit to file descriptor n,
>> or the standard output (file descriptor 1) if n is not
>> specified.
>
> Not sure
Christian Krause wrote:
> Given all of these facts I still tend to say that the bash shouldn't
> filter them...
There's always the following argument:
"Other characters may be permitted by an implementation; applications
shall tolerate the presence of such names."
I agree with Christian here. A
Hello Chet,
hello Raph,
I was involved in the discussion on IRC (Freenode / #bash) yesterday,
maybe I can give one or the other comment.
It took a while for us to find out why it happens. When we knew it, and
after some discussion, we agreed that the easiest way would be to make
Bash able to init
Sandino Araico Sánchez wrote:
>1.
> #!/bin/bash
>2.
>
>3.
> for i in {0..15000} ; do
>4.
> echo $i > /dev/null
>5.
> done
>
>
>
> Repeat-By:
> Run the script above and the process starts leaking memory very
> fast.
>
>
Y
Ray Parrish wrote:
> bash: printf: 08: invalid number
> 0
> bash: printf: 09: invalid number
Arithmetic expression/base specifications:
http://bash-hackers.org/wiki/doku.php/syntax/arith_expr#different_bases
Seems to apply for all numerical formats for printf, too.
J.
Mike Coleman wrote:
> [Oops--I sent that incomplete.]
>
> It would be nice if there was some really brief syntax for
>
> $(type -p somecommand)
>
> I find myself using this all day long with 'ls', 'file', 'ldd',
> 'strings', 'nm', etc., and the current incantation is just long enough
> to be
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
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
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 *
1 - 100 of 167 matches
Mail list logo
