Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux treehug.home.kurahaupo.gen.nz 5.15.0-73-generic #80-Ubuntu
SMP Mon May 15 15:18:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x8
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='ba
Lese selbst:
http://www.npd.de/npd_info/deutschland/2004/d1204-24.html
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
uot;
wait "$job_pid" || echo "wait failed!"
}
$ ./bash wait-for-child-ok
main pid: 664705
job pid: 664706
command group pid: 664705
^ OK
Martin
On 6/22/21 6:15 AM, Chet Ramey wrote:
On 6/22/21 5:42 AM, Martin Jambon wrote:
Hello!
I ran into something that looks like a bug to me, although I'm not
super familiar curly-brace command groups.
It's not the brace command; it's the pipeline.
Thank you! It's the $$ th
On 6/22/21 4:31 AM, Greg Wooledge wrote:
On Tue, Jun 22, 2021 at 02:42:40AM -0700, Martin Jambon wrote:
I ran into something that looks like a bug to me, although I'm not super
familiar curly-brace command groups.
Bash version: latest from GitHub mirror (commit ce23728: Bash-5.1 pa
On 6/22/21 1:37 PM, Greg Wooledge wrote:
On Tue, Jun 22, 2021 at 01:12:10PM -0700, Martin Jambon wrote:
On 6/22/21 4:31 AM, Greg Wooledge wrote:
A pipeline creates two or more subshells, one for each command in the
pipeline. Therefore, your wait command is running in a different
process than
On 6/22/21 5:00 PM, Lawrence Velázquez wrote:
Maybe something like this would get the point across:
($$) Expands to the process ID of the shell. In a subshell,
it expands to the value that $$ has in the invoking shell.
It's better. However, the reader is still left wonder
On 6/22/21 6:11 PM, Lawrence Velázquez wrote:
On Tue, Jun 22, 2021, at 8:52 PM, Martin Jambon wrote:
It's better. However, the reader is still left wondering what "the
shell" is referring to in first sentence.
Subshells aside, I have a hard time believing that "the pro
On 6/23/21 6:24 AM, Chet Ramey wrote:
On 6/22/21 9:54 PM, Martin Jambon wrote:
In the posix definition, a subshell
- is not necessarily implemented as a separate process
- belongs to a unique shell
- is not a shell
Why is it not "a shell?"
Because '$$' doesn't mat
h no characters between last \\n and EOF"
printf '%s\n' "$input" | sed 's/Incomplete l/L/' | while read -E line; do
printf ' %s\n' "$line"; done
<<<
The patch has not been tested intensely - first I would like to hear if I'm on
a
t;lastvar" (b) is
> empty, and therefore the incomplete line isn't counted. I consider
> this a feature, but others may not.
Yes, one might discuss this...
Nevertheless, am I right that this solution relies on an undocumented feature?
Best regards
Martin
t; now.
Before reading the source I would never have thought that read sets variables
although it returns FAILURE.
Best regards
Martin
Hello David!
> I guess 99% of programmers would either expect "Finished" to be printed or
> some syntax error.
Well, 99% of shell programmers will (hopefully ;-) ) put a blank between "{"
and "echo" in the line
foo="$(testCode)" || {echo "foo";}
Best regards
Martin
writing new shell scripts
at all - for example use python instead. There are many historically founded
flaws and odds with shell proramming.
Anyhow, bug-bash@gnu.org is not the right place for these topics, better try
help-b...@gnu.org.
Best regards
Martin
at stripped down version:
$ bash --noprofile --norc -i -c "echo \$BASH_VERSION; shopt -s expand_aliases ;
source <(echo \"alias x='echo hallo'\"); alias; x"
5.1.4(1)-release
alias x='echo hallo'
bash: x: command not found
Best regards
Martin
doesn't save much compared to
egrep2() { grep -E "$@" ; }
Or is there a reason why one shouldn't use this in an interactive shell?
Best regards
Martin
e signal wasn't caught (which didn't really surprise me).
Best regards
Martin
ormation
$
Now you can go on as expected, the last command in history is $'echo\n\'))' and
the 'sleep ...' is not in the history at all.
I would either have expected to get PS2 and no error messages after entering
the line starting with sleep or being able to just enter the next command.
Best regards
Martin
y ignoring this.
If this is expected behavior man page should be updated as those
arguments are not ignored any more.
martin
the
advantage of a "maximum source nesting level exceeded" error over a
segmentation fault?
Next we will need MAXARRUSAGE, MAXBRACEEXPAN, ...
> There's a slim chance this might be exploitable.
I would really be interested in an example.
Best regards,
Martin
my sourceables also need logic to prevent them from being executed by
>accident (they tell you to source them instead).
Just don't give them execute permission (at least when running on a unix
system).
Best regards,
Martin
uot; result.
In case there is some reason not to use /dev/tty, wouldn't it then be better to
ask stdin instead of stderr? The script will most probably be interested in the
size of device it is writing to, not the one it is logging to.
Best regards
Martin
Hello Dale!
> Martin Schulte writes:
> > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11)
> > seems to determine LINES and COLUMNS from stderr.
>
> It's not clear to me that the manual page says where the LINES and
> COLUMNS values are ob
Hello Chet,
on 2022-07-18 10:26:05 -0400 you wrote:
> On 7/16/22 11:18 AM, Martin Schulte wrote:
> > Hello,
> >
> > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11)
> > seems to determine LINES and COLUMNS from stderr.
>
> ...
>
Hi!
> Running with this assumption, now that we know bash's extglob matching
> will not perform suitably for this task, we can look at other approaches.
Here's another:
printf -- '%s ' $(gcc --help) | sed 's/ $/\n/'
Let just do the shell most of the work ;-)
Best regards,
Martin
'%s\n' format in the first place, and skip the sed/tr.
I just changed the last one!
Best regards,
Martin
Hello!
> function sa {
> for y in $(seq $1 $e2); do
> echo "echo search $y "
> done
> }
I assume you should write $2 instead of $e2 in line 2.
Best regards,
Martin
is intended...
Best regards,
Martin
argument test
Try
type -a echo
and
Echo() {
echo test }
Echo test
}
Echo
to get an insight was is happening.
So, it's no surprise that bash finally crashes.
Most probably you want to insert a ; before the first closing }:
echo() { echo test ; }
But even now bash will crash.
Best regards
Martin
his something
> that should be changed?
I assume this is because sleep "exits" with an exit status of 148
(=128+SIGTSTP) when it is stopped. If you replace the && with an ;, you get
"yes" immediately after pressing ^Z.
Best regards
Martin
ast in Debian 11 the default ~/.profile cares for sourcing ~/.bashrc, that
might explain the effect you describe.
Best regards,
Martin
Hi Chet!
> Thanks for the report. The synopsis should read
>
> cd [-L|[-P [-e]]] [-@] [dir]
^ ^
But aren't these two brackets just superfluous?
Best regards,
Martin
s
> supplied.
Yes, my feeling was just that | has such a low precedence that the marked pair
of brackets could be omitted, like in
id|cut -c1-3
or in the ERE
^(-L|-P( -e)?)?$
But situation seems to be different here.
Best regards,
Martin
;().[]*}"'
test{<()
$ dash-c 'option2="test{<().["; echo "${option2%%[<().[]*}"'
test{
Am I missing something?
I tried to find a smaller example showing the difference but so far I didn't
succeed.
Best regards,
Martin
t terminate bash.
- When exit is invoked with a non-numeric first argument it terminates bash.
That seems to be inconsistent with the behaviour described before, while the
exit status of the shell is 2 and consistent in some way.
Best regards
Martin
; $ ${ case }x in \}x) echo uname; esac }
> Linux
I couldn't reproduce this with neither 5.1.4 nor 5.2.15 - in both cases
${ case } in }) echo uname; esac }
results in
bash: syntax error near unexpected token `)'
Any help appreciated!
Thanks,
Martin
} ~root xterm-256color 2024-01-12 42 /dev/fd/63 hello
So, everything works fine execept filename expansion, which seems to be missing.
Or do I understand something wrong?
Best regards,
Martin
>
> So, everything works fine execept filename expansion, which seems to be
> missing.
>
> Or do I understand something wrong?
>
> Best regards,
>
> Martin
ecognisable as a new-style function,
sound software engineering principles would come down firmly on 'no'.
> | even when we claim it's local" and "unset can even mess with the poor
> | protection afforded by 'local'".
>
> I'm guessing you mean bash's bizarre unset definition wrt locals.
> I consider that to just be a bug.
Yes that's the one, and I agree it's a bug.
But now it's also an implementation "feature" that people may rely on. I've
heard rumours that 'upvar' needs it, so I would want to hear from people who
have a use for its current behaviour, before deciding to "fix" it.
-Martin
Il 03/04/24 15:10, Martin Guy ha scritto:
The "unlimited" keyword is not mentioned in the manual page, and
should be.
Oops. Yes it is. Only dash lacks a mention of it. Sorry for the noise.
M
OpenPGP_signature.asc
Description: OpenPGP digital signature
Hi.
ulimit -c unlimited
The "unlimited" keyword is not mentioned in the manual page, and should be.
(nor is it for dash(1) so it looks like someone copied some else's
manual page!)
With thanks
M
OpenPGP_signature.asc
Description: OpenPGP digital signature
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown'
-DLOCALEDIR='/home/mjackson/src
I didn't see any acknowledgement of this bug report, did I fill in enough
info?
Thanks & regards,
Martin Jackson
On Tue, Mar 5, 2013 at 1:52 PM, Martin Jackson
wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-g
ect.
Even after unsetting IGNOREEOF, the shell exits. The set -o ignoreeof
by itself does not make the shell ignore EOF; the only way seems to be
to set IGNOREEOF to a very large number.
Thanks,
Martin
It seams that "cd [/]{1,}" should take you to the root node. (as showed up
by 'ls')
But when we try with two "/" something goes wrong:
ls works as to be in the root node,
pwd report "//" as path instead of "/"
the bash line report "//" as path too
How to reproduce:
user@pc:/home/user$
me in Cc since I am not on the list.
Thanks,
Joel Martin (kanaka)
From 04df5a7a23325a7e9b42ee3d4b306fa222326d99 Mon Sep 17 00:00:00 2001
From: Joel Martin
Date: Tue, 12 Nov 2013 15:30:47 -0500
Subject: [PATCH] Listening socket support via /dev/tcp/HOST/:PORT
In addition to the ability to creat
by
this addition?
Regards,
Joel Martin (kanaka)
On Wed, Nov 13, 2013 at 1:35 AM, Piotr Grzybowski wrote:
> Hi Everyone, hi Joel,
>
> the idea is nice, and I can really see that it is useful, but I would
> be extremely careful with introducing those kind of changes, it can be
>
being spawned. However, with this model
the implementation is very straight forward and the interface it exposes is
basically the same as creating an outgoing socket. But the point here is
about adding a very useful utility to bash, not about allowing a bash
script to implement a high performance and fully robust server.
Regards,
Joel Martin (kanaka)
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
I chose to avoid '-s' because it's
rather ambiguous in this context: single? signal? status? stopped? Long
option names might also be nice.
Waiting for multiple processes (but not all) presents some challenges; Perl
implements this by waiting for all, and stashing the statuses until the
script actually waits for them.
-Martin
89three 09.749212492four 09.761410711ubuntu@ubuntu:~$ foo2one
11.805819275four 11.819741270three 11.828260887two 11.829470548
Fix:
Use a single-line alias. Or use the "&&" operator to chain commands (which
changes the functionality to be short-circuit evaluations).
Also verified this behavior on RHEL6 with bash 4.1.2(1).
Thanks!Andrew Martin
1410711
ubuntu@ubuntu:~$ foo2
one 11.805819275
four 11.819741270
three 11.828260887
two 11.829470548
Fix:
Use a single-line alias. Or use the "&&" operator to chain commands
(which changes the functionality to be short-circuit evaluations).
Also verified this behavior on RHEL6 with bash 4
Hello,
I've found this bug, when changed an string variable to hash, but left the
following code for test of zero code. It happens just inside function. I'm
using 4.1.2(1)-release,
BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:expand_aliases:extquote:force_fignore:hostcomplete:interactive_co
s for history-search-forward.
--
Lincoln Martin <[EMAIL PROTECTED]>
_
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.7
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.7' -DCONF_MACHTYPE='sparc-sun-solaris2.7'
-DCONF_VENDOR='sun' -DSHELL -DHAVE_CONFIG_H -D_LARGEFIL
Bob Proulx wrote:
Martin Wheatley wrote:
You also asked ...
Is there an example of
another command shell which handles this situation in a different and
possibly better way?
/bin/sh handles the situation correctly (in our opinion)
On my system /bin/sh is a symlink to /bin/bash and
Bob Proulx wrote:
Please keep your replies to the mailing list to keep everyone involved
in the discussion instead of singling out one individual. Also the
mailing list is archived and others may search the archive to find
previous discussions.
Martin Wheatley wrote:
The following can be
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux
Compiler: gcc -I/usr/src/packages/BUILD/bash-2.05b
-L/usr/src/packages/BUILD/bash-2.05b/../readline-4.3
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i
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='b
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.7
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.7' -DCONF_MACHTYPE='sparc-sun-solaris2.7'
-DCONF_VENDOR='sun' -DLOCALEDIR='/usr/local/depot/bash-3.
Configuration Information [Automatically generated, do not change]:
Machine: sparc
OS: solaris2.7
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc'
-DCONF_OSTYPE='solaris2.7' -DCONF_MACHTYPE='sparc-sun-solaris2.7'
-DCONF_VENDOR='sun' -DLOCALEDIR='/usr/local/depot/bash-3.
. Idea is from pdksh. At least 3.2 doesn't have
such a patch, I didn't look though all the patches after 3.2, however.
Martin--- bash/jobs.c.origWed Jun 20 00:02:39 2007
+++ bash/jobs.c Sun Sep 16 23:29:41 2007
@@ -1611,6 +1611,7 @@
{
sigset_t set, oset;
pid_t pid;
+ un
$ ./my.sh
bash: func: line 2: syntax error near unexpected token `('
bash: func: line 2: ` done <<(ps -ef);'
bash: error importing function definition for `func'
In our shell.
./my.sh: line 3: func: command not found
Done with shell.
--
Jeffery Martin
hi!
i'm stuck into a strange problem. i'm piping the output of one program into a
textfile, and with a ruby script i'm parsing it. it works fine on my laptop,
but on the pc i need it to install the output in the file is blocked every 10
seconds. the parser has therfore a delay of maximal 10 sec
> > i'm stuck into a strange problem. i'm piping the output of one
> > program into a textfile, and with a ruby script i'm parsing it.
>
> Did you mean redirecting to a text file? Piping implies that there is
> a program reading from the pipe but then there wouldn't be any files
> involved.
yes.
Ken Irving wrote:
> Try comparing terminal settings on each platform, e.g., with stty -a,
> and look into any differences.
they are the same on both machines:
[EMAIL PROTECTED]:~$ stty -a
speed 38400 baud; rows 55; columns 160; line = 12;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; e
Base
Specifications Issue 6, IEEE Std 1003.1, 2004 Edition).
This may be useful:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
Thanks for bash, it rocks... :-)
peace & happiness,
martin
>>>>> "Paul" == Paul Jarc writes:
Paul> "Martin Schwenke" wrote:
>> Neither bash.info or bash(1) documents parameter expansion of
>> the form:
>>
>> ${parameter+word}
Paul> It's documented, but it&
is unset.
Bob> Then searches on ":" would also find that descriptive text
Bob> too.
I agree.
However, I would still suggest going further and including at least
one full example.
peace & happiness,
martin
r:~# bash t
+ echo 1
1
+ echo x
+ grep -v x
With dash (same output for lenny and testing):
foobar:~# dash t
+ echo 1
1
+ echo x
+ grep -v x
+ echo 2
2
--
Martin Michlmayr
http://www.cyrius.com/
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPA
on. Maybe CHANGES can be updated to list all
the changes that were made as a consequence of the Austin Group's
interpretation.
--
Martin Michlmayr
http://www.cyrius.com/
Thank you for setting me straight! I had checked the POSIX spec
before sending the report but missed the part about the delimiter
having to be immediately followed by newline.
Martin
On 09/24/2009 06:39 AM, Chet Ramey wrote:
Machine Type: i386-redhat-linux-gnu
Bash Version: 4.0
Patch Level
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDI$
uname output: Linux bristol 2
Thank you for all and sorry for the noise, you were right.
David.
On Thu, Sep 24, 2009 at 6:38 PM, Chris F.A. Johnson
wrote:
> On Thu, 24 Sep 2009, David Martin wrote:
>
>> Configuration Information [Automatically generated, do not change]:
>> Machine: x86_64
>> OS: li
y be done using a out=$(cmd) subprocess... except in
the case where cmd can block before producing all of its
output. Hence, the above seems convenient.
Repeat-By:
See above.
Fix:
I'd expect a fix to be tricky... which probably explains the
current behaviour. ;-)
peace & happiness,
martin
producing data. It's equivalent to a pipeline, except that
> the reader doesn't need to be in a subshell.
Thanks, I'll use that unless I can come up with something more
portable! :-)
peace & happiness,
martin
thing like:
"31125 49710-06:28:15"
The process number is correct AFAIK, but the uptime is miles too big and seems
to vary between: 49710-06:28:01 and 49710-06:28:15.
Repeat-By:
Repeating the command until it happens again.
--
Regards,
Martin Nicholas.
E-mail: [EMAIL PROTECTED]
_
nformation originally sent to bug-bash@gnu.org was
incorrect. The correct version is above.
My humble apologies.
Repeat-By:
Repeating the command until it happens again.
--
Regards,
Martin Nicholas.
E-mail: [EMAIL PROTECTED]
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Hello,
I'm running bash under Debian Stretch:
$ echo $BASH_VERSION
4.4.12(1)-release
$ trap
$ echo $$
1100
$ kill 1100
$
=> Looks fine for me
Then I do a
kill 1100
from another session and the bash above terminates.
=> Looks wrong for me
Greetings,
Martin
quot; as strongly
deprecated in the help page or remove it at all from test rather than
thinking about if this is a bug and how to fix it.
There's a related discussion in the coreutils mailing list:
http://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00117.html
Regards,
Martin
hare/gnuconfig/config.sub x86_64-pc-linux-gnu
x86_64-pc-linux-gnu
-
Thank you.
Regards,
Martin
On 1/18/19 1:44 PM, Chet Ramey wrote:
On 1/17/19 6:21 PM, Drab Martin wrote:
Hi,
I have a problem with bash 5.0:
-
machine1 ~ # bash --version
GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or
${x@Q}'
+ bash -c 'set -o nounset; echo ${x/a/b}'
bash: x: unbound variable
"GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)" behaves
identically.
So, @Q breaks the 'set -o nounset'.
Is this intended?
I like using @Q for output of variables with unknown content - is there a
better way to do this?
Best regards,
Martin
Hello!
> Is there a T/F var expansion that does:
>
> var=${tst:+$yes}${tst:-$no}
>
> but with yes/no in 1 expansion?
At least if you are only working with numbers you can use
((var=(tst!=0?42:31)))
But is this a question for bug-bash?
Best regards,
Martin
9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11)
x86_64 GNU/Linux
$ echo $BASH_VERSION
4.4.12(1)-release
Sorry, I would like to be more helpful - but maybe someone else has
noticed a similiar problem or has an idea with the sources in mind.
Best regards,
Martin
27; a
Z [ ] ^ _ ` a
It looks as if the backslash (between [ and ] in ASCII code) is missing in
brace expansion. The same behaviour seems to be found in bash 5.0.
Best regards,
Martin
Hi Chet, hi all!
On Thu, 5 Dec 2019 12:01:31 -0800
Chet Ramey wrote:
> On 12/5/19 11:11 AM, Martin Schulte wrote:
> > Hello,
> >
> > please have a look:
> >
> > $ uname -a
> > Linux martnix4 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2
> > (2019-1
Hello,
thanks a lot for all the answers!
I would like to suppose (Ilkka already argued in this direction) that in
future versions of bash {x..C} should expand to x y z A B C.
Best regards,
Martin
-A assoc=()
echo ${#assoc[@]} # Are there elements in it?
assoc[key1]=val1
assoc[key2]=
for key in key1 key2 key3; do
if [[ -n ${assoc[$key]+isset} ]]; then
echo "Element for $key is set"
else
echo "No Element for $key"
fi
done
Best regards,
Martin
. –
No. It works as intended. It's not usable in a pipe in the way you try,
but this is caused by the principles of a pipe, not by a bug in read.
while ! read -t 0; do
echo 'It works as intended - just press RETURN to see why'
done
Best regards,
Martin
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash
es sourcing the file if it is invoked
non-interactively.
But, as far as I understand, a non-interactive bash doesn't read
~/.bashrc at all - so shouldn't we just omit them?
Best regards,
Martin
./time_gettimeofday |
egrep '\.(00|99)
shows it is right...
Thanks and best regards,
Martin
tes *or as the right-hand
side of an variable assignment*, word splitting and filename expansion are
not performed on the results.
at end of 3.5.4.
Best regards,
Martin
-n$'\n'
will print a -n in the bash.
Best regards
Martin
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-sec$
uname output: Linux t1 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24)
x
ts and other compound commands.
> Bash has always behaved this way.
>
> However, invalid parameter transformation operators are not considered
> fatal errors, even in posix mode. Maybe they should be.
Yes, please :-)
Or no error at all.
Best regards
Martin
echo "${x;:-}" ; echo "Not executed"
echo "Executed"
echo "${x:-}" ;; echo "Not executed"
echo "Not executed"
<<<
It just a source of problems that the two syntactical errors (both caused by an
extra semicolon) lead to different behaviour.
Martin
1 - 100 of 378 matches
Mail list logo
