an=ar1
> echo ${#!an[@]}
> -bash: ${#!an[@]}: bad substitution
>
> This works but feels kludgy
>
> an=ar1
> eval echo \${#$an[@]}
> 4
I'm not quite sure what exactly you intend, but if you use
declare -n an=ar1
instead of an=ar1, then
echo ${#an} ${an[3]}
will work as I expect.
Best regards
Martin
an=ar1
> echo ${#!an[@]}
> -bash: ${#!an[@]}: bad substitution
>
> This works but feels kludgy
>
> an=ar1
> eval echo \${#$an[@]}
> 4
I'm not quite sure what exactly you intend, but if you use
declare -n an=ar1
instead of an=ar1, then
echo ${#an} ${an[3]}
will work as I expect.
Best regards
Martin
bytes themselves.
To be exact, this is already caused by a Unix Kernel - strings passed by the
exex* system calls are null terminated, too. As it is the default in the C
programming language. Thus you can't pass a null byte in an argument when
invoking a program.
Best regards
Martin
e.g. another incompatibility between the
builtin and the external echo.
Best regards
Martin
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-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale
On 04/28/2015 08:26 AM, Chet Ramey wrote:
On 4/27/15 1:26 PM, Martin Sebor wrote:
Bash Version: 4.3
Patch Level: 33
Release Status: release
Description:
When the PROMPT_COMMAND variable is set to a command such a printf
it causes the cursor to jump to disappear or jump to the wrong
positions
Surely a pipe counts as an explicit redirection?
And even if it didn't, the inconsistency between the first and subsequent
asynchronous elements is confusing.
On 12 Jan 2016 02:41, "Chet Ramey" wrote:
> On 1/10/16 12:54 PM, Piotr Grzybowski wrote:
> > hey,
> >
> > I am quite sure it happens her
quot; but it fails to
mention that this applies to pipes as well; so I submit that it is a
reasonable interpretation that a pipe on an outer block counts as an
(explicit) redirection for the purpose of reading the "Asynchronous Lists"
sub section.
What do other shells do? Ksh? Dash? Zsh?
-Martin
On 13 Jan 2016 8:14 p.m., "Andreas Schwab" wrote:
> I don't think so.
>
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07
> doesn't mention pipelines.
That was rather my point. Given that they aren't mentioned, one has to take
them as read, otherwise even ( ( foo
n its parts.
But we have to assume it does, otherwise all manner of stuff is broken, even
though they haven't written it.
-Martin
On Wed, 13 Jan 2016, Chet Ramey wrote:
> On 1/13/16 4:08 AM, Andreas Schwab wrote:
> > Martin Kealey writes:
> >
> >> What do other shells do? Ksh? Dash? Zsh?
> >
> > $ ksh -c 'printf "foo1\nfoo2\n" | { (read x; echo 1: $x) & (read x; echo
arg3
$
I am on Gentoo Linux:
# emerge -pv app-shells/bash
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R] app-shells/bash-4.4_p5-r1::gentoo USE="net nls (readline) -afs
-bashlogger -examples -mem-scramble -plugins" 0 KiB
Thank you for comments,
Martin
Hi,
I forgot to say thanks to all of you who responded. I think the manual page
needs improvement. This is just confusing.
Martin
Eric Blake wrote:
> On 12/27/2016 10:21 AM, Martin MOKREJŠ wrote:
>> Hi,
>> I wanted to enable error code reporting for piped processes. This
>
ted to match any new available levels.
What was the original purpose of this? Was it just to double-check that
there weren't bugs in the rest of the shell_compatibility_level logic?
If so, would it be acceptable to omit this check from my new version?
-Martin
PS: This patch is dependent on a
l
$ echo !!:$
echo /dev/null
/dev/null
5.2 states (correctly from my point of view):
_ ... Subsequently, expands to the last argument to the previous simple command
executed in the foreground, after expansion. ...
$ echo hello > /dev/null
$ echo $_
hello
Best regards,
Martin
iately close
Is there maybe something broken in your setup?
Best regards,
Martin
is broken in bash 5.1 POSIX mode unless patch
> 13 is applied:
> https://lists.gnu.org/archive/html/bug-bash/2022-01/msg8.html
Thanks for the explanation!
Martin
-c 'echo $BASH_VERSION; PATH=~/x:~/y; echo $PATH'
5.1.4(1)-release
/home/schulte/x:~/y
$ bash-5.2.37 --posix -c 'echo $BASH_VERSION; PATH=~/x:~/y; echo $PATH'
5.2.37(1)-release
/home/schulte/x:/home/schulte/y
Best regards,
Martin
;stty -a" and "bind -p"
so that the current settings are recorded in the output log; then exit the
shell to close the script session.
As there are some significant caveats, please read "man script" (or
https://man7.org/linux/man-pages/man1/script.1.html) before doing this
rately whether the file exists.
-Martin
quot; works. In both cases the variable "x"
is visible to (and modifiable by) everything that is called from "main"; so
everything is inside the "main" function, "local" there is quite
indistinguishable from true global.
-Martin
Modules can have conflicting requirements of global settings that require
weird contortions to interoperate; so starting out by making this yet
another global setting seems like a retrograde step.
So I would like to propose an alternative approach.
Firstly, I would reduce the action to simply "re
setting is
perpetuating the "wrong direction"; "local -" has the same dynamic scope as
any other "local", which means magic action at a difference, and makes
brittle code that can abort unexpectedly in production.
-Martin
empty is zero" behaviour as we get when
writing "var" without a radix prefix.
But my real point is that I shouldn't have to come here and make that
point; rather, avoiding breaking changes, even "in the name of making
scripts less buggy", should be the standing policy.
extending from the current statement
until the end of the inner-most enclosing compound statement, or the end of
an explicit subshell, or the end of the file, or the end of the string
that's being read by "eval"; whichever comes first.
I'm in two minds whether this should be s
tion back when it was
added to the Bourne shell; the only saving grace then was that shell
scripts were rarely longer than a page, so it didn't matter as much.
I've just run a test in Bash v1.14.7 and (not unexpectedly) "set -e" had
the same effect there.
-Martin
Hi Steffen, thanks for that.
It will be especially useful for defining (( MAXINT = ~0 >>> 1 )).
This reminds me of some other operations I've been meaning to implement,
including true modulus +% (where the sign of the result always matches the
divisor) with the corresponding flooring division +/
Printf %u already reveals the word size, as do most kinds of overflow -
albeit messily, like $((3**40))
At least by explicitly exposing the word size in a controlled manner, we
can write code that avoids unintended overflow.
-Martin
On Sun, 17 Jul 2022, 11:54 Dale R. Worley, wrote:
> Stef
not being surprised by its behaviour. In my book that
ranks such a shell as *more* complicated than one that does use floating
point (or bignums).
Case in point: just a few days ago we had a bug report from someone
complaining that the exponentiation operator gave the wrong result, because
they didn'
her to introduce
new commands or options to get the new behaviours (*2).
What consideration was given to creating “local --unset *VAR*” or “unset
--local *VAR*” or some other equivalent that doesn't overload any existing
command form?
-Martin
*1: To my mind, shopt compatNN is broken in a
h-4.4+ [i.e., behavior
> (B)] is nothing wrong as it is effectively unspecified, but behavior (A)
> seems still more reasonable to me. Behavior (B) is a source of problems
>
I concur with this assessment.
-Martin
his is so that cut can be implemented as a small
state machine using just getchar, putchar, and a counter. This avoids
copying via a line buffer, and that implies there should be no line-length
limit.
So I'm a bit surprised that any kind of "getline" is used by the loadable
version.
If you expect LD_PRELOAD to incorporate code into Bash itself, then you
need to set it before you launch Bash; setting it once Bash is running is
too late.
What exactly is the LD_PRELOAD loading for you, and what does THAT do?
On Thu, 18 Aug 2022, 09:19 , wrote:
> Because I'm using Android, And
low new scripts to be written without needing to
constantly work around misfeatures that are 35 years past their use-by date.
Which is it to be?
-Martin
PS: top of my list of most-hated misfeatures isn't any of the POSIX
malapropisms, but rather the fact that we can't write "shopt comp
ot;gcc -std=c23" will reject such code.
Of course, compilers are unlikely to remove their compatibility modes any
time soon, but I would hate to be stuck in a position of requiring "gcc
-std=gnu23" to get both new *and* obsolete features at the same time.
-Martin
the literal text, so that when it later turns out that the variable is
an assoc array, it can use that rather than the expression tree. This would
of course suppress reporting expression syntax errors using bash -n.
-Martin
On Mon, 5 Sep 2022, 05:49 Yair Lenga, wrote:
> Putting aside th
c indexing and slicing, so we don't have
to resort to run-time lookup to figure out whether it should have been
parsed as a numeric range expression (after we've already done so).
And it leaves space in the syntax of dot-things to add operators we've
haven't considered yet; perhaps
On Wed, 7 Sept 2022 at 18:13, Yair Lenga wrote:
> Thanks for providing feedback and expanding with new ideas.
>
> I believe the summary is:
>
> ${a.key1.key2} - Static fields
> ${a.key1.$key2} - Mixed dynamic/static, simple substitution.
> ${a.key1.{complex.$key2}} - For complex keys that may co
be used in scripts. Of
course this advisory has to actually show the characters that it's telling
you to avoid.
Or do you think it should also tell you to avoid:
declare -a foo="(1 2)"
declare -a foo=\(1\ 2\)
-Martin
Regression appears to have occurred between bash-5.0.18 and bash-5.1-alpha
at commit 712f80b0. (I note that this commit is missing from the master
branch, which only includes bash-5.0.17 at commit.)
I tried to find the change in the devel branch, but ugh, git diff between
devel & master is unhelpf
n
name and source filename and line, though I can see the latter being
somewhat tricky if it's created inside an eval.
-Martin
On Thu, 6 Oct 2022 at 08:29, Robert Elz wrote:
> Date:Wed, 5 Oct 2022 15:36:55 -0400
> From:Chet Ramey
> Message-ID: &l
>
> 1) [...] string should be limited to PATH_MAX [...]
> 2) [...] have a fix recursion deep level [...]
> 3) [...] Implement a stack deep check in the recursion [...]
4) compile globs into state machines, the same way that regexes get
compiled, so that they can be matched without needing any recursion.
-Martin
s private settings and forming a
closure to keep that access even after the outer function returns (never
possible in Bash because dynamic scope doesn't work that way)
3. simply written one inside the other (possible as demonstrated by your
own example above);
4. being hidden except when inside the outer function (always possible with
unset -f or with the proposed function -L, never possible otherwise)
-Martin
d need a stack to be treated
as magic match-never tokens.
I say "extglob", but this would also speed up silly ordinary globs like
[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]*[a-z]
-Martin
On Tue, 11 Oct 2022 at 15:57, Phi Debian wrote:
>
>
> On Tue,
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux … 5.18.16-…-amd64 #1 SMP PREEMPT_DYNAMIC Debian
5.18.16-… (2022-…) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.2
Pat
This seems like a good reason to simply translate extglobs into regexes,
which should run in linear time, rather than put effort into building and
debugging a parallel implementation.
-Martin
PS: While we're about it, can we please fix the expansion of « a/*/b/c/d/*
» so it only calls readd
eem like a fairly serious issue if it's present in the 5.2.0
release.
-Martin
there is an increasing number of common new utilities that don't
honour the POSIX requirements for a text stream, such as 'jq' in its
"brief" mode; if you come across these, please file bug reports on them. If
the maintainers push back, please point them at the POSIX standard.
-Martin
On Sat, 29 Oct 2022 at 22:15, Greg Wooledge wrote:
> On Sat, Oct 29, 2022 at 04:50:00PM +1100, Martin D Kealey wrote:
> > This seems like a good reason to simply translate extglobs into regexes,
> > which should run in linear time, rather than put effort into building and
the OS. The hard part is what to do with
(!LIST), which was the point of my previous post.
-Martin
On Sun, 30 Oct 2022 at 23:35, Oğuz İsmail Uysal
wrote:
> On 10/30/22 3:25 PM, Martin D Kealey wrote:
> > How much faster do you think it can be made?
> I don't know, irrelevant though.
lease have an immediate point release turning this feature off by
default, and then let's take another look at how this can be done without
gratuitous breakage of existing code.
-Martin
PS:
I'm puzzled why a bare '&' was chosen in the first place; that seems to
provide
The expansion `$[var+replacement}` was part of the Bourne shell when I used
it in 1985 (before POSIX was first published), whereas `test A -gt B` is
rather newer, and `test -v` is only a Bash extension (and similarly wasn't
added until later).
The man and info pages have retained the rather terse
ld be:
```
declare ARGS=$( getopt -o "$S_OPTS" -l "$L_OPTS" -n "$0" -- "$@" )
ERRORS=$?
(( ERRORS == 0 )) || usage
```
or:
```
declare ARGS ERRORS=0
ARGS=$( getopt -o "$S_OPTS" -l "$L_OPTS" -n "$0" -- "$@" ) ||
usage
```
-Martin
(PS: "Working" would be questionable, since putting `getopt` in a subshell
prevents it from updating "$@"; and `test $? = 0` and its variants are
pointless clutter.)
BASH_XTRACEFD=1
to
exec {BASH_XTRACEFD}>&1
-Martin
whitespace
4. push these latter strings onto the front of argv
5. replace the exec path with a copy of (the new) argb[0]
6. re-start the execve procedure
Failing to make the substitution in step 1 would leave the interpreter
running but with no idea how to open the script so that it could run it.
-Martin
>
d an interactive shell in a tty without job control in
the last 35 years. (*1)
I contend that it's past time this POSIX misfeature was retired.
In the meantime, « shopt -s background_without_magic » (*2) gets my vote,
along with incorporating « nohup » as a built-in (so that Bash can
guar
than add more weirdness to the behaviour.
-Martin
On Fri, 3 Feb 2023 at 07:17, Chet Ramey wrote:
> On 1/28/23 5:56 AM, Martin D Kealey wrote:
> > Firstly, let's just leave aside "POSIX requires this" for a bit.
> Be that as it may, POSIX exists and this is a requirement. It's also how
> other shells behave.
&
t;don't use after" date, so that script writers
don't have to cope with broken versions potentially remaining forever?
-Martin
PS: the current "beta testing" arrangement seems to me to have too few
participants by at least two orders of magnitude. We need to encourage
&
in subshells of a
session shell that has job control enabled, even though they don't actually
do job control themselves. Maybe there should be an 'M' in $- when job
control is actually active (in the top level session shell). What do others
think about this?
- Martin
mpilers prior to C99.
I would like a planning discussion for general future directions,
preferably taking Bash towards a regular language, with POSIX compliance
and "old Bash" compliance as shims.
If we're just going to accept breaking changes willy-nilly, we make a lie
of that stability. If we're not going to compensate by making linguistic
and structural improvements, then in my opinion the only honest thing to do
is to shut down the entire project: Bash 5.1 should be the last ever
release.
-Martin
ctually need it turned on, and
turning it off would break it.
There's no good reason to turn off extglob if you're writing a new script,
as it only affects the validity of some very weird corner cases.
# Without extglob this is a function definition;
# with extglob it's an empty gl
ut any syntax element into an alias and the shell will parse it.
>
We can quibble about contextual details and whether "syntax element"
distinguishes "reserved word" from other "word" lexical tokens, but
otherwise that's adequate.
-Martin
PS: I also fudged thing
I suspect the history file is corrupt; truncating a file while another
process has it open for writing can do strange things.
On Sun, 19 Feb 2023, 23:05 Mr. Dick Steel, wrote:
> WARNING: The following will REPLACE your
> current .bash_history file! Take care.
>
> 1. Start you term
I suggest avoiding enumerating exclusions (including removing any existing
ones), and adding an explanation that "expansions that can produce multiple
words are excluded".
On Wed, 15 Mar 2023, 15:52 Alex Bochannek, wrote:
> Chet,
>
> Thank you for the thoughtful responses. My thoughts below got
On Fri, 24 Mar 2023 at 10:42, William Kennington via Bug reports for the
GNU Bourne Again SHell wrote:
> It would be nice if $SECONDS was using `clock_gettime(CLOCK_MONOTONIC,
> &val)` as it would usually make the most sense when you want to know the
> time since the script started.
Generally n
aper than the
alternatives, so I don't see any likelihood of this *becoming* a problem
for Bash in the future. (For other projects, sure, but not for Bash.)
All that said, I'm all for tidying up the code so that it can compile
cleanly and run reliably.
-Martin
On Mon, 27 Mar 2023 at 09:50,
d keeping function types clear is really
important.
-Martin
Is there any chance that your history contains a raw escape sequence that
trigger the terminal to report attributes using `CSI…c` as described in the
first answer to
https://stackoverflow.com/questions/29939026/what-is-the-ansi-escape-code-sequence-escc
Using "tail" would limit the output to just
words at all; and then the "b" stands alone as the only text on the line.
-Martin
On Fri, 14 Apr 2023 at 04:38, James Cloos wrote:
> with bash-5.0.3, !foo-b reports
> b
> bash: b: command not found
>
> even when foo-bar is in history.
>
> there is nothing in the histo
could observe a difference in behaviour with
this change? (Maybe some crazy self-modifying script exists somewhere, but
I can't imagine such a thing being particularly stable if it's relying on a
*failure*.
Would even a single person be negatively impacted by fixing this?
ange.
> ((code == 127)) && break
> ((!code)) || status=$code
> done
> return $status
> }
>
> # Eventually finishes:
> while true; do (
> true &
> false &
> waitjobs
> ) && break; done
>
I'm testing with Bash 5.1.4p47
-Martin
ou care to speculate more precisely on where such silent reaping may
occur, given the code as shown?
-Martin
PS: I'm not convinced that “trap ... SIGCHLD” needs to be in that list;
it's the “wait” inside the trap that actually matters, and if you *don't*
“wait” inside a SIGCHLD trap, things are going to get quite strange anyway.
ting.
2. ${#array[@]} gives the number of elements rather than the last index
(minus 1). Being able to declare an array as non-sparse (so that all gaps
"exist" with some default value) would fix this.
-Martin
I was heading with my suggestion
about non-sparse arrays.
On Mon, 22 May 2023 at 07:01, Martin D Kealey
wrote:
[...]
> 2. ${#array[@]} gives the number of elements rather than the last index
> (minus 1). Being able to declare an array as non-sparse (so that all gaps
> "exist" with some default value) would fix this.
>
-Martin
text.
I think that cure would be worse than the disease, because it has
undesirable hidden effects on operator precedence and order of evaluation.
-Martin
On Tue, 23 May 2023 at 23:32, Chet Ramey wrote:
> On 5/22/23 10:56 PM, Martin D Kealey wrote:
>
> > For example, if one is filling an array in random order, rather than
> > progressively adding to the end, then it is useful and makes sense to be
> > able to ask the arr
On Sun, 11 Jun 2023, 09:31 Grisha Levit, wrote:
> The command printing code can fail to add a required semicolon when the
> last word in the command ends with `&'
>
This could be obviated by unconditionally outputting a newline instead of a
semicolon.
I acknowledge that this style isn't to ever
of case is incomplete.)
-Martin
Hi Alex
Is your history set to line mode or command mode? This changes whether
recalling a multi-line history item gets put in the input buffer all at
once or only one line of it, and that in turn changes whether you see PS2
in between the lines.
On Sat, 24 Jun 2023, 03:34 alex xmb ratchev, wrot
shift ; done
printf %s\\n "${@%%=*}"
}
eval "$( typeset -p )"
)
```
or
```
(
declare -a var_names=()
function declare {
local v
for v do
[[ $v = -* ]] ||
var_names+=("${v%%=*}")
done
}
eval "$( typeset -p )"
unset -f declare
n Mon, 26 Jun 2023 17:09:47 +1000
> Martin D Kealey wrote:
>
> > Hi Eli
> >
> > How about using the shell itself to parse the output of "typeset" (an
> alias
> > for "declare"), but redefining "declare" to do something different. This
>
refix,
> 0xDIGITS, still allows just "0x" as a valid zero constant.
>
> Not sure whether this should be considered a bug,
> and whether it's worth fixing - just letting you know.
>
No, definitely not. It's established behaviour, and should not be removed
without an explicit shopt.
--
-Martin
t an ssh key
only allows one particular command to be run. (Use multiple keys if you
have multiple commands you want to run.)
-Martin
On Fri, 14 Jul 2023 at 09:47, Grisha Levit wrote:
> This patch implements the ksh93-style <<# redirection operator to enable
> indentatable heredocs.
On the whole I think this is great, and thankyou for working up the patch,
but I would like to offer some comments and suggestions:
Firstly, it'
esn't
conflict with the other forms above.
Then we can write:
cat <<##|
| line 1 indent 2 space
|line 2 no indent
(No EndMark is necessary; we simply stop when we reach a line that does not
start with C.)
-Martin
-F \([^ ]*\).*/\1/p' )
-Martin
cture of the code, not the literal
text. We expect it to exclude comments, extra blank lines, and names of
aliases where they are used.
Unless you actually need to modify how a script is PARSED, don't use
aliases; use functions instead.
-Martin
PS: please use structure-indicative indentation when showing examples.
rk-around is to enable alias expansion in scripts.
*Grumble*
-Martin
PS: and people think I'm crazy for wanting to write new stuff in Perl, in
preference to Bash. Bash as a language has nothing else going for it, so if
after 28 years I still can't consider it stable, what is the point?
>
useful. (Non-local continue is a logical extension of that.)
Saying that this *ought* to be done using aliases is not reasonable, as it
means forgoing the other stuff that functions can do, like taking
parameters, declaring local variables, or returning a status.
-Martin
On Fri, 21 Jul 2023, 04:09 Greg Wooledge, wrote:
> On Fri, Jul 21, 2023 at 12:33:07AM +1000, Martin D Kealey wrote:
> > Saying that this *ought* to be done using aliases is not reasonable, as
> it
> > means forgoing the other stuff that functions can do, like taking
> &g
trying to "fix" this will have unintended consequences and likely
break existing valid code.
On the other hand, since everyone has now had 36+ years to update their
scripts to get rid of backticks, maybe it's time to start issuing a warning
when they're used at all? 🤪
-Martin
>
ng for a quote mark or other closing token, meaning
that it may still exit immediately despite that setting.
(The number assigned to IGNOREEOF indicates how many times you have to type
ctrl-D to cause the Shell to exit. Numbers in the range 3-15 can be useful)
-Martin
On Sun, 30 Jul 2023, 08:22 Chet Ramey, wrote:
> On 7/28/23 1:51 PM, Martin D Kealey wrote:
>
> > maybe it's time to start issuing a warning
> > when [backticks are] used at all? 🤪
>
> There's no reason to use `` over $(...), but that form is still a required
ould recommend turning on histreedit, so that it's less cumbersome to
fix any unexpected history expansions.
$ echo $(( ! 0 ))
1
$
Please don't go breaking existing functionality just because someone can't
imagine a use for it.
-Martin
with "The selected
line…", to differentiate from the line just entered containing a "!".
If you want to rearrange things, it should go immediately after describing
phase 2.
-Martin
On Tue, 15 Aug 2023 at 01:41, Chet Ramey wrote:
> On 8/11/23 4:19 PM, Martin D Kealey wrote:
> > I think it would be helpful to start this sentence with "The selected
> > line…", to differentiate from the line just entered containing a "!".
>
> It
lem is that colon's own exit status is always zero,
and that will prevent the exit status of the preceding command from
propagating out of a case/esac block or out of a function.
-Martin
the Shell language.
Sadly most script writers have not even read Bash's own documentation, much
less read and understood the POSIX standard.
-Martin
On Sat, 19 Aug 2023, 04:27 Malena Arduino via Bug reports for the GNU
Bourne Again SHell, wrote:
> To whom it may concern,
>
> I am wo
could make things worse in corner
cases, and could conceivably break scripts that rely on the current
behaviour.
-Martin
>
101 - 200 of 384 matches
Mail list logo
