In Debian, shell scripts that have
#!/usr/bin/sh
as the first line are executed by the 'dash' shell.
If you write such scripts, you might be interested
to know that 'dash' currently has a behaviour
change in Debian version 12 Bookworm compared to
Debian version 11 Bullseye.
This is being discussed at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028002
Below is a demo of the change which shows an
example of possible consequences.
In Debian version 11 Bullseye,
Bash and 'dash' behave the same:
$ cat /etc/debian_version
11.6
$ mkdir eek
$ cd eek
$ touch aa bb 11 22
$ bash
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
aa bb
$ sh
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
aa bb
In Debian version 12 Bookworm,
Bash and 'dash' behave differently:
$ cat /etc/debian_version
12.0
$ mkdir eek
$ cd eek
$ touch aa bb 11 22
$ bash
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
aa bb
$ sh
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
11 22 <------ new behaviour by dash
When I write bash scripts and I've done this for several debian versions I use:
#!/usr/bin/env bash
That has worked in the past.
-- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that
order." Ed Howdershelt 1940.
On Thu, 13 Apr 2023, David wrote:
In Debian, shell scripts that have
#!/usr/bin/sh
as the first line are executed by the 'dash' shell.
If you write such scripts, you might be interested
to know that 'dash' currently has a behaviour
change in Debian version 12 Bookworm compared to
Debian version 11 Bullseye.
This is being discussed at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028002
Below is a demo of the change which shows an
example of possible consequences.
In Debian version 11 Bullseye,
Bash and 'dash' behave the same:
$ cat /etc/debian_version
11.6
$ mkdir eek
$ cd eek
$ touch aa bb 11 22
$ bash
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
aa bb
$ sh
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
aa bb
In Debian version 12 Bookworm,
Bash and 'dash' behave differently:
$ cat /etc/debian_version
12.0
$ mkdir eek
$ cd eek
$ touch aa bb 11 22
$ bash
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
aa bb
$ sh
$ echo [!0-9]*
aa bb
$ echo [^0-9]*
11 22 <------ new behaviour by dash
$ echo [^0-9]*
11 22 <------ new behaviour by dash
On Thu, Apr 13, 2023 at 12:12:23AM +0000, David wrote:
$ echo [^0-9]*
11 22 <------ new behaviour by dash
The [^chars] syntax is a negation in Basic and Extended Regular
Expressions, and in bash's globs (it's a bash extension), but NOT in
POSIX globs.
The correct negation syntax in POSIX sh globs is [!chars].
On Thu, Apr 13, 2023 at 12:12:23AM +0000, David wrote:[...]
$ echo [^0-9]*
11 22 <------ new behaviour by dash
The correct negation syntax in POSIX sh globs is [!chars].
Help by adding links to BashFAQ, StackOverflow, man pages, POSIX, etc
On 13/04/2023 08:07, Greg Wooledge wrote:
On Thu, Apr 13, 2023 at 12:12:23AM +0000, David wrote:[...]
$ echo [^0-9]*
11 22 <------ new behaviour by dash
The correct negation syntax in POSIX sh globs is [!chars].
The shellcheck utility gives this suggestion as well. Their wiki have
concise description of the issue, but links describing it in more details with precise references have not been added yet.
https://www.shellcheck.net/wiki/SC3026
Help by adding links to BashFAQ, StackOverflow, man pages, POSIX, etc
Anyway, here's the POSIX documentation section:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#t ag_18_13
And the relevant piece of text:
[ If an open bracket introduces a bracket expression as in XBD RE
Bracket Expression, except that the <exclamation-mark> character
( '!' ) shall replace the <circumflex> character ( '^' ) in its
role in a non-matching list in the regular expression notation, it
shall introduce a pattern bracket expression. A bracket expression
starting with an unquoted <circumflex> character produces unspecified
results. Otherwise, '[' shall match the character itself.
On Thursday, April 13, 2023 10:36:08 PM Greg Wooledge wrote:
[ If an open bracket introduces a bracket expression as in XBD RE
Bracket Expression, except that the <exclamation-mark> character
( '!' ) shall replace the <circumflex> character ( '^' ) in its
role in a non-matching list in the regular expression notation, it
shall introduce a pattern bracket expression. A bracket expression
starting with an unquoted <circumflex> character produces unspecified
results. Otherwise, '[' shall match the character itself.
Wow -- I thought this was an English language list :-(
But seriously, that seems very hard to interpret / understand.
On Thursday, April 13, 2023 10:36:08 PM Greg Wooledge wrote:
Anyway, here's the POSIX documentation section:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#t ag_18_13
And the relevant piece of text:
[ If an open bracket introduces a bracket expression as in XBD RE
Bracket Expression, except that the <exclamation-mark> character
( '!' ) shall replace the <circumflex> character ( '^' ) in its
role in a non-matching list in the regular expression notation, it
shall introduce a pattern bracket expression. A bracket expression
starting with an unquoted <circumflex> character produces unspecified
results. Otherwise, '[' shall match the character itself.
Wow -- I thought this was an English language list :-(
But seriously, that seems very hard to interpret / understand.
As to [^c] vs. [!c], unfortunately the latter can not be always used as portable variant. It is treated as history expansion in the case of interactive bash session.
On Fri, Apr 14, 2023 at 09:08:08AM +0700, Max Nikulin wrote:
https://www.shellcheck.net/wiki/SC3026Well, it's not clear how to actually add such a link. I guess you're supposed to do it through github or something?
Help by adding links to BashFAQ, StackOverflow, man pages, POSIX, etc
On Sat, Apr 15, 2023 at 09:44:03AM +0700, Max Nikulin wrote:
As to [^c] vs. [!c], unfortunately the latter can not be always used as portable variant. It is treated as history expansion in the case of interactive bash session.
Ugh. That abomination. I've had history expansion disabled for *years*.
On Fri, Apr 14, 2023 at 11:02:03PM -0400, Greg Wooledge wrote:
On Sat, Apr 15, 2023 at 09:44:03AM +0700, Max Nikulin wrote:
As to [^c] vs. [!c], unfortunately the latter can not be always used as
portable variant. It is treated as history expansion in the case of
interactive bash session.
Ugh. That abomination. I've had history expansion disabled for *years*.
You have to escape it with a backslash. Quoting with single quotes also helps, although I don't know whether that is portable itself.
Yes, somewhat annoying, unless one's making use of it.
On 15/04/2023 12:02, tomas@tuxteam.de wrote:
On Fri, Apr 14, 2023 at 11:02:03PM -0400, Greg Wooledge wrote:
On Sat, Apr 15, 2023 at 09:44:03AM +0700, Max Nikulin wrote:
As to [^c] vs. [!c], unfortunately the latter can not be always used as portable variant. It is treated as history expansion in the case of interactive bash session.
Ugh. That abomination. I've had history expansion disabled for *years*.
You have to escape it with a backslash. Quoting with single quotes also helps, although I don't know whether that is portable itself.
The problem is to prevent history expansion while keeping pattern matching (glob) active.
du -ks -- .[!.]* | sort -n | tail
On 15/04/2023 12:02, tomas@tuxteam.de wrote:
On Fri, Apr 14, 2023 at 11:02:03PM -0400, Greg Wooledge wrote:
On Sat, Apr 15, 2023 at 09:44:03AM +0700, Max Nikulin wrote:You have to escape it with a backslash. Quoting with single quotes also
As to [^c] vs. [!c], unfortunately the latter can not be always used as >>>> portable variant. It is treated as history expansion in the case of
interactive bash session.
Ugh. That abomination. I've had history expansion disabled for *years*. >>
helps, although I don't know whether that is portable itself.
The problem is to prevent history expansion while keeping pattern matching (glob) active.
du -ks -- .[!.]* | sort -n | tail
On Sat, 15 Apr 2023 Max Nikulin wrote:
The problem is to prevent history expansion while keeping pattern
matching (glob) active.
du -ks -- .[!.]* | sort -n | tail
Are there versions of bash that exhibit history expansion in the
example above?
On Sat, Apr 15, 2023 at 11:02:12AM +0000, davidson wrote:
On Sat, 15 Apr 2023 Max Nikulin wrote:
The problem is to prevent history expansion while keeping pattern
matching (glob) active.
du -ks -- .[!.]* | sort -n | tail
Are there versions of bash that exhibit history expansion in the
example above?
Not that I've found. I tried 3.2 and 2.05b and they're both fine.
History expansion is performed immediately after a complete line is...
read, before the shell breaks it into words, and is performed on each
line individually.
the history expansion character is also treated as quoted if it
immediately precedes the closing double quote in a double-quoted string.
BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.
On 15/04/2023 19:37, Greg Wooledge wrote:
On Sat, Apr 15, 2023 at 11:02:12AM +0000, davidson wrote:
On Sat, 15 Apr 2023 Max Nikulin wrote:
The problem is to prevent history expansion while keeping pattern matching (glob) active.
du -ks -- .[!.]* | sort -n | tail
Are there versions of bash that exhibit history expansion in the
example above?
Not that I've found. I tried 3.2 and 2.05b and they're both fine.
I am really sorry. I have checked the terminal app buffer where I was experimenting with history expansion and almost certainly I
misinterpreted some result.
I see that inside square brackets expansion of exclamation mark is
suppressed when (and only when) it immediately follows the opening
bracket.
- [!c] is safe
- [a-f!@1-2] and [0-9!] are affected by history expansion
(and it is likely the source of my confusion)
BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.
On 18/04/2023 21:19, Vincent Lefevre wrote:
BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.
It would be great. Unfortunately disabling histexpand option in bash blocks the M-^ shortcut as well.
shopt -s histverify
allows at least to confirm that expansion result is expected.
On Wed, 19 Apr 2023 Max Nikulin wrote:
On 18/04/2023 21:19, Vincent Lefevre wrote:
BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.
It would be great. Unfortunately disabling histexpand option in bash blocks >> the M-^ shortcut as well.
shopt -s histverify
allows at least to confirm that expansion result is expected.
There is also the 'p' (print) word designator, that prints the
expansion but does not execute it. Used like so:
$ !.:p # See what the history expansion for 'dot' is
. .bash_functions/manterm
This places the expansion in history as last command, so up-arrow +
return will now execute it.
On Wed, 19 Apr 2023 Max Nikulin wrote:
On 18/04/2023 21:19, Vincent Lefevre wrote:
BTW, history expansion can be very useful, but IMHO, this should
have been interactive and triggered by control characters or
escape sequences, not by "normal" characters.
It would be great. Unfortunately disabling histexpand option in bash
blocks the M-^ shortcut as well.
shopt -s histverify
allows at least to confirm that expansion result is expected.
There is also the 'p' (print) modifier, that prints the
expansion but does not execute it. Used like so:
 $ !.:p # See what the history expansion for 'dot' is
 . .bash_functions/manterm
This places the expansion in history as last command, so up-arrow +
return will now execute it.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 39:48:16 |
| Calls: | 6,910 |
| Files: | 12,376 |
| Messages: | 5,428,984 |