Robert Elz wrote in
<19942.1742090...@jacaranda.noi.kre.to>:
|Date:Sun, 16 Mar 2025 02:35:12 +0100
|From: Steffen Nurpmeso
|Message-ID: <20250316013512.2aC3SIyk@steffen%sdaoden.eu>
|
|| The problem is not an empty field.
|
|Your problem might not be
Robert Elz wrote in
<21988.1742085...@jacaranda.noi.kre.to>:
|Date:Sat, 15 Mar 2025 23:41:45 +0100
|From: Steffen Nurpmeso
|Message-ID: <20250315224145.YPWRnxq7@steffen%sdaoden.eu>
|
|| * Expands to the positional parameters, start
Steffen Nurpmeso wrote in
<20250315225314.0SShmWUW@steffen%sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20250315224145.YPWRnxq7@steffen%sdaoden.eu>:
||Robert Elz wrote in
|| <8711.1742074...@jacaranda.noi.kre.to>:
| ...
|| * Expands to the positional parameters,
Steffen Nurpmeso wrote in
<20250315224145.YPWRnxq7@steffen%sdaoden.eu>:
|Robert Elz wrote in
| <8711.1742074...@jacaranda.noi.kre.to>:
...
| * Expands to the positional parameters, starting from one,
|initially producing one field for each positional parameter that
|
Robert Elz wrote in
<8711.1742074...@jacaranda.noi.kre.to>:
|I should have added in my last reply that if you want to investigate
Before i apologise to Greg Wooledge i want to point out that POSIX
says:
* Expands to the positional parameters, starting from one,
initially producing one fie
Hello Robert.
Robert Elz wrote in
<25006.1741917...@jacaranda.noi.kre.to>:
|Date:Fri, 14 Mar 2025 01:34:48 +0100
|From: Steffen Nurpmeso
|Message-ID: <20250314003448.DdqG5Ont@steffen%sdaoden.eu>
|
|| I am deeply sorry, but i have one more difficulty
Greg Wooledge wrote in
<20250314024153.gh22...@wooledge.org>:
Sorry Mr., but i have problems with your attitude; you also seem
to have confused yourself, and i unfortunately thing that was not
accidental.
But thank you.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich mu
Hello again.
I am deeply sorry, but i have one more difficulty that i fail to
explain to myself. It *could* (small, very small case) be that
this time the incorrectness really is on the side of bash.
This script (do not care for the commented, they are great)
a() {
echo $#,1="$1"/$1,2="$2"
P.S.:
the full test (proof, as bash is the example i compare against)
script is this:
# proof {{{
a() {
b() {
echo "b=$# 1<$1> 2<$2> 3<$3> 4<$4> 5<$5> 6<$6> 7<$7> 8<$8>
9<$9> 10<${10}> 11<${11}> 12<${12}> 13<${13}> 14<${14}> 15<${15}> 16<${16}>
17<${17}> 18<${18}> 19<${19
Steffen Nurpmeso wrote in
<20250204231325.B4BPBm8Q@steffen%sdaoden.eu>:
|Robert Elz wrote in
| <6584.1738633...@jacaranda.noi.kre.to>:
||Date:Mon, 03 Feb 2025 19:00:28 -0500
||From:Zeffie via Bug reports for the GNU Bourne Again SHell \
||
||
Robert Elz wrote in
<6584.1738633...@jacaranda.noi.kre.to>:
|Date:Mon, 03 Feb 2025 19:00:28 -0500
|From:Zeffie via Bug reports for the GNU Bourne Again SHell \
|
|Message-ID: <875b2e87e5d847a4aa04ba2b31bec...@zeffie.com>
...
|| The debug headers indicate an "
Chet Ramey wrote in
:
|On 1/12/25 6:25 PM, Steffen Nurpmeso wrote:
|
|> Should be doable for bash in the "no-argument" case, which
|> currently works though POSIX requires at least one argument:
|
|If `read' isn't supplied any variable name arguments, bash ass
Greg Wooledge wrote in
<20250112215505.gb27...@wooledge.org>:
|On Sun, Jan 12, 2025 at 16:26:04 -0500, Chet Ramey wrote:
|>> In this case, we get the "expected" result:
|>
|> You just restated the original example while ignoring the part of my
|> message about looking for additional input af
..sorry..
--- Forwarded from Steffen Nurpmeso ---
Date: Wed, 23 Oct 2024 00:39:14 +0200
Author: Steffen Nurpmeso
From: Steffen Nurpmeso
To: chet.ra...@case.edu
Subject: Re: 5.2.37: bg(1)ed job then only runs partially
Message-ID: <2024103914.Qg9LVo-4@steffen%sdaoden.eu>
Chet Ramey
Hello.
So first: this thread must not even start if the answer is "bash
justs sends a signal to the job's entire process group, if the
programs do not properly deal with that it cannot help that".
(ogg123 in particular is known to have signal issues.)
This just in case possible changes brought in
Hello Robert.
Thanks again for your extensive answers.
Robert Elz wrote in
<2675.1726728...@jacaranda.noi.kre.to>:
|Date:Thu, 19 Sep 2024 00:45:44 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240918224544.aXWgbZu-@steffen%sdaoden.eu>
|
|| Woops
Robert Elz wrote in
<5996.1726697...@jacaranda.noi.kre.to>:
|Date:Wed, 18 Sep 2024 23:05:06 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240918210506.9rRUe2TG@steffen%sdaoden.eu>
|
|| I am totally surprised they all swallow this code, there is no
|
Chet Ramey wrote in
:
|On 9/18/24 1:05 AM, Oğuz wrote:
|> On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso \
|> wrote:
|> It boils down to this:
|>
|>f(){ echo $#;}; set "" "" ""; IFS=x; f $*
|>
|> bash, NetBSD and FreeBSD sh, and
Robert Elz wrote in
<3946.1726671...@jacaranda.noi.kre.to>:
...
|| On Wed, Sep 18, 2024 at 08:05:10 +0300, Oğuz wrote:
||> It boils down to this:
||> f(){ echo $#;}; set "" "" ""; IFS=x; f $*
|
||> bash, NetBSD and FreeBSD sh, and ksh88 all agree and print 2. pdksh
||> prints 3 but mksh
Oğuz wrote in
:
|On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso \
|wrote:
|>
|
|It boils down to this:
In this case, ok .. i have not spent time trying to vaporise it.
I haved added this standalone thing to my tests.
| f(){ echo $#;}; set "" "" "";
Hello.
I am terribly sorry to be here once again; i already mentioned on
bug-bash@ the problem with IFS being reverse solidus that dash
(and myself) has (have).
I came back to this for my one again, and i stumble over one
additional difference in behaviour in between (myself and) bash,
dash and bu
Chet Ramey wrote in
:
|On 8/29/24 2:17 PM, Robert Elz wrote:
|> Date:Thu, 29 Aug 2024 10:40:25 -0400
|> From:Chet Ramey
|> Message-ID:
|>
|>| It's not a big problem. You're in the background if your process \
|>| group is
|>| not equal to the terminal's p
Robert Elz wrote in
<23591.1724975...@jacaranda.noi.kre.to>:
|Date:Fri, 30 Aug 2024 00:39:40 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240829223940.CDUfy6-w@steffen%sdaoden.eu>
|
|| On Linux it seems not even to cause TTOU if you set
|| attribut
Martin D Kealey wrote in
:
|On Fri, 30 Aug 2024 at 04:17, Robert Elz wrote:
|> SIGTTOU is also sent, unconditionally, by any attempt to change any of
|> the terminal's attributes, and the process (group) (by default) stops.
|> (I don't recall off hand whether simply fetching the attributes is
Chet Ramey wrote in
:
|On 8/28/24 4:12 PM, Steffen Nurpmeso wrote:
|> Chet Ramey wrote in
|> <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>:
|>|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
|>|> I got a bug report for my mailer which stated
|>|>
|>|&
Robert Elz wrote in
<25564.1724955...@jacaranda.noi.kre.to>:
|Date:Thu, 29 Aug 2024 10:40:25 -0400
|From:Chet Ramey
|Message-ID:
|
|| It's not a big problem. You're in the background if your process group is
|| not equal to the terminal's process group.
|
|Th
902...@jacaranda.noi.kre.to>:
|Date:Wed, 28 Aug 2024 02:03:54 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240828000354.qZaQvm7v@steffen%sdaoden.eu>
|
|| That confuses me again, unfortunately i got a bug report and
|| distracted. I mean, i would
||
|| 1.
Martin D Kealey wrote in
:
|On Thu, 29 Aug 2024 at 06:12, Steffen Nurpmeso wrote:
|> Chet Ramey wrote in
|> <3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>:
|>|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
|>|> ..and it seems that if bash starts a normal process then IC
Chet Ramey wrote in
<3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>:
|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
|> Hello.
|>
|> I got a bug report for my mailer which stated
|>
|> $ ( echo blah | Mail root ) &
|>[1] 2754649
|> $ ^M^M^M^
Robert Elz wrote in
<14146.1724799...@jacaranda.noi.kre.to>:
|Date:Tue, 27 Aug 2024 22:02:34 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240827200234.95X76_wN@steffen%sdaoden.eu>
|
|
|| Any character in IFS delimits a field, adjacent IF
Steffen Nurpmeso wrote in
<20240827234659.1xfh6CZb@steffen%sdaoden.eu>:
...
|..and it seems that if bash starts a normal process then ICRNL is
|set, but if it starts a (process)& or only process&, then not!
Yeah, and it seems to me it should not, since programs have to
fetc
Hello.
I got a bug report for my mailer which stated
$ ( echo blah | Mail root ) &
[1] 2754649
$ ^M^M^M^M^C^C
[1]+ Stopped ( echo blah | Mail root )
$ fg
( echo blah | Mail root )
$
I turns out i answered him now
The thing is that if i apply the patch (this
Chet Ramey wrote in
:
|On 8/26/24 8:21 PM, Steffen Nurpmeso wrote:
|> Chet Ramey wrote in
|> :
|>|On 8/23/24 5:47 PM, Steffen Nurpmeso wrote:
|>|> If IFS has a value other than the default, then sequences of the
|>|> whitespace characters space, tab, and newli
Lawrence Velázquez wrote in
<972ac206-a601-4337-8dfc-77bbaef22...@app.fastmail.com>:
|On Sat, Aug 24, 2024, at 10:08 PM, Steffen Nurpmeso wrote:
|> One hopefully last thing in this regard for me,
...
|This easily obfuscates the structure of the "$@" expansion. You
alex xmb sw ratchev wrote in
:
|try
|
|${@@Q}
|
|and
|
|${*@Q}
|
|greets
I try to avoid using non-portable shell stuff.
I do not think these would be understood by the ash shell variants
(and ksh) which had results other than bash.
--steffen
|
|Der Kragenbaer,The moon be
Chet Ramey wrote in
:
|On 8/23/24 5:47 PM, Steffen Nurpmeso wrote:
|> If IFS has a value other than the default, then sequences of the
|> whitespace characters space, tab, and newline are ignored at the
|> beginning and end of the word, as long as the whitespace
|> cha
Dear Robert, all.
Robert Elz wrote in
<39.1724620...@jacaranda.noi.kre.to>:
|Date:Sun, 25 Aug 2024 04:08:58 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240825020858.nrX4pFTm@steffen%sdaoden.eu>
|
|| (The only thinkable answer is that the step that
Robert Elz wrote in
<26326.1724474...@jacaranda.noi.kre.to>:
|Date:Fri, 23 Aug 2024 23:47:06 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240823214706.oskn9OEF@steffen%sdaoden.eu>
|
|| So IFS whitespace only if part of $IFS.
|
|That is the defin
Greg Wooledge wrote in
:
|On Sat, Aug 24, 2024 at 02:15:48 +0200, Steffen Nurpmeso wrote:
|> a() {
|> echo $#,1=$1,2=$2,"$*",$*,
|>}
|
|You didn't read a word I said, did you
I recognize that i did not get your email even though i was in Cc:.
|*Sigh
Emanuele Torre wrote in
:
|On Sat, Aug 24, 2024 at 02:15:48AM +0200, Steffen Nurpmeso wrote:
|> Sorry but i really have to come again, i do not understand what is
|> going on, and *i* think shell is at fault.
|
|No. It is working correctly.
|
|> This:
|>
|> a() {
|
Steffen Nurpmeso wrote in
<20240825013311.B3Z3QcNn@steffen%sdaoden.eu>:
|Robert Elz wrote in
| <26326.1724474...@jacaranda.noi.kre.to>:
||Date:Fri, 23 Aug 2024 23:47:06 +0200
||From: Steffen Nurpmeso
||Message-ID: <20240823214706.oskn9OEF@ste
Sorry but i really have to come again, i do not understand what is
going on, and *i* think shell is at fault.
This:
a() {
echo $#,1=$1,2=$2,"$*",$*,
}
echo "$*"$* $*; a "$*"$* $*
echo __
IFS=:;echo "$*"$* $*; a "$*"$* $*;unset IFS
echo ==
set -- a b c
echo "$*"$* $*; a "$*"$*
Greg Wooledge wrote in
:
|On Fri, Aug 23, 2024 at 01:28:49 +0200, Steffen Nurpmeso wrote:
|> a() { echo $#,1=$1,2=$2,"$*",$*,; }
|> set -- a b c
|> echo 2
|> IFS=:; echo "$*"$*; a $* "$*";
I want to point out that bash in particular has
Hello.
Sorry for being here again, rather bash unrelated mostly..
Steffen Nurpmeso wrote in
<20240816215210.PMy3rwiy@steffen%sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20240816212216.accse4FG@steffen%sdaoden.eu>:
||Robert Elz wrote in
|| <16443.1723841...@jacaranda.noi.kre.to
Steffen Nurpmeso wrote in
<20240816212216.accse4FG@steffen%sdaoden.eu>:
|Hello kre@.
|
|Robert Elz wrote in
| <16443.1723841...@jacaranda.noi.kre.to>:
||Date:Thu, 15 Aug 2024 23:33:42 +0200
||From: Steffen Nurpmeso
||Message-ID: <20240815213342.t
Hello kre@.
Robert Elz wrote in
<16443.1723841...@jacaranda.noi.kre.to>:
|Date:Thu, 15 Aug 2024 23:33:42 +0200
|From: Steffen Nurpmeso
|Message-ID: <20240815213342.t6-hdjZT@steffen%sdaoden.eu>
|
|| I have extended the test a bit, and i also se
One more, please.
(And please excuse this still copies bug-bash.)
Steffen Nurpmeso wrote in
<20240815184858.r5T_UQnM@steffen%sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20240814200534.Vh3Eu_Md@steffen%sdaoden.eu>:
||Chet Ramey wrote in
|| <1bba673e-5ab9-4263-9d88-124854
Hello.
Unfortunately i have to add one thing to this thread..
Steffen Nurpmeso wrote in
<20240814200534.Vh3Eu_Md@steffen%sdaoden.eu>:
|Chet Ramey wrote in
| <1bba673e-5ab9-4263-9d88-124854793...@case.edu>:
||On 8/13/24 8:45 PM, Steffen Nurpmeso wrote:
||> I include bug-bas
Hello.
I only respond to this to reduce the noise.
Chet Ramey wrote in
<1bba673e-5ab9-4263-9d88-124854793...@case.edu>:
|On 8/13/24 8:45 PM, Steffen Nurpmeso wrote:
|> I include bug-bash even though i think bash is correct, but there
|> lots of people of expertise are listeni
Hello.
I include bug-bash even though i think bash is correct, but there
lots of people of expertise are listening, so, thus.
Sorry for cross-posting, nonetheless.
Given this snippet (twox() without argument it is)
one() { echo "$# 1<$1>"; }
two() { one "$@"; }
twox() { one "$@$@"; }
two
Greg Wooledge wrote in
:
|On Thu, May 23, 2024 at 06:56:01AM +0800, Dan Jacobson wrote:
|> It seems these should both make one line "+ a=b c=b" output,
|>
|> for s in sh bash
|> do $s -xc 'a=b c=$a'
Only to note that this is not portable.
The FreeBSD shell will not assign "b" to "c" for thi
Koichi Murase wrote in
:
|2023年12月10日(日) 15:58 Koichi Murase :
|> 2023年12月10日(日) 14:13 Martin D Kealey :
...
|> I'm not a big fan of `10#[-+]digits' and invalidating `10#' either
...
|I checked the behaviors of different shells because I was interested
|in them. They seem to vary more than
Chet Ramey wrote in
:
...
|It's still accepted in the devel branch, unless STRICT_ARITH_PARSING is
|defined. There was a discussion about it in 2022:
|
|https://lists.gnu.org/archive/html/bug-bash/2022-07/msg00045.html
You surely mean
https://lists.gnu.org/archive/html/bug-bash/2022-07/ms
Chet Ramey wrote in
<7402031f-424c-4766-ba70-71771c9dc...@case.edu>:
|On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
|> The "problem" with the current way bash is doing it is that bash's
|> job handling does not recognize jobs die under the hood:
|>
|&g
Greg Wooledge wrote in
:
|On Fri, Nov 10, 2023 at 06:59:10PM +0100, Steffen Nurpmeso wrote:
|> Sequences are also bash-only (though seq(1) is
|> everywhere).
|
|It most definitely is *not* everywhere. It's part of GNU coreutils,
|and is generally not present on any system that
Chet Ramey wrote in
<7402031f-424c-4766-ba70-71771c9dc...@case.edu>:
|On 11/8/23 8:12 PM, Steffen Nurpmeso wrote:
|> The "problem" with the current way bash is doing it is that bash's
|> job handling does not recognize jobs die under the hood:
|>
|&g
Hello.
Oğuz wrote in
:
|On Thursday, November 9, 2023, Steffen Nurpmeso wrote:
|> I mean some scripting on "jobs | wc -l" would do that, though. :(
|> Maybe i should just write a function that builds the string
|> necessary to do what i wanted with %* or "%1-2 %4&quo
Greg Wooledge wrote in
:
|On Thu, Nov 09, 2023 at 10:17:35PM +0100, Andreas Schwab wrote:
|> On Nov 09 2023, Greg Wooledge wrote:
|>> re='^\[([0-9]+)\]'
..
|>> while IFS= read -r line; do
|>> if [[ $line =~ $re ]]; then
...
|> That fails for multi-line commands that happen
Robert Elz wrote in
<15529.1699569...@jacaranda.noi.kre.to>:
|Date:Thu, 9 Nov 2023 16:55:50 -0500
|From:Greg Wooledge
|Message-ID:
|
|| I believe *nothing* would work in that case;
|
|There's no requirement (in fact, it is probably not a good idea) for
|newli
Robert Elz wrote in
<7989.1699564...@jacaranda.noi.kre.to>:
|Date:Thu, 09 Nov 2023 21:04:28 +0100
|From: Steffen Nurpmeso
|Message-ID: <20231109200428.8g9lz%stef...@sdaoden.eu>
|
|| ash(1) and busybox ash(1) do not even support jobs -l in a functio
Andreas Schwab wrote in
<87h6lueids@igel.home>:
|On Nov 09 2023, Greg Wooledge wrote:
|
|> re='^\[([0-9]+)\]'
|> jobspecs=()
|> while IFS= read -r line; do
|> if [[ $line =~ $re ]]; then
|> jobspecs+=( "%${BASH_REMATCH[1]}" )
|> fi
|> done <
Greg Wooledge wrote in
:
|On Thu, Nov 09, 2023 at 08:09:23PM +0100, Steffen Nurpmeso wrote:
|> j() {
|> local j= a=${AWK:-awk}
|> [ $# -gt 0 ] && j='&& $2 !~ /(^| )('$(echo "$@" | tr ' ' '|')')( \
|>
alex xmb sw ratchev wrote in
:
...
|> So i did that (what a mess -- does anyone know how i can create an
|> awk regular expression where parts of the expression is a variable
|> that should be expanded? ugh! what do i know??):
|
|awk -v var1='cont ent' -vv2="$other' ' { code } '
|
|keep
Steffen Nurpmeso wrote in
<20231109181645.bocyg%stef...@sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20231109181107.bj0wl%stef...@sdaoden.eu>:
||Steffen Nurpmeso wrote in
|| <20231109011212.tc9hj%stef...@sdaoden.eu>:
|| ...
||Something like this that would be, adding J
Steffen Nurpmeso wrote in
<20231109181107.bj0wl%stef...@sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20231109011212.tc9hj%stef...@sdaoden.eu>:
| ...
|Something like this that would be, adding JLIST_SPEC_ONLY and
|jobs(1) -j. Just in case of interest.
I mean some scripting on &
Steffen Nurpmeso wrote in
<20231109011212.tc9hj%stef...@sdaoden.eu>:
...
Something like this that would be, adding JLIST_SPEC_ONLY and
jobs(1) -j. Just in case of interest.
diff --git a/builtins/jobs.def b/builtins/jobs.def
index 1ce098d08b..989a78079e 100644
--- a/builtins/jobs.def
Hello.
Well first i was thinking of a "%*" special so i can say
"kill %*", but get_job_spec() and usage does not look promising.
The task: close all jobs at once (and dreaming of
%ID1-%ID2,ID3-ID4, etc). Ie i often (really) am doing things that
require many instances of less(1), or git(1) log, a
Stephane Chazelas wrote in
<20230902084912.vdfedsgbnat2w...@chazelas.org>:
|2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \
|Open Group:
...
|>|FWIW, a "printf %b" github shell code search returns ~ 29k
|>|entries
|>|(https://github.com/sear
Stephane Chazelas via austin-group-l at The Open Group wrote in
<20230901181024.pwx4plwclz7ij...@chazelas.org>:
|2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
...
|> How many scripts in the wild actually use %b, though? And if there
|> are such scripts, anything
Chet Ramey wrote in
<2fd2ed52-3272-3433-6179-164bc5122...@case.edu>:
...
|> At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote:
|>> In the bash manual page (`man bash`), the ASCII tilde character '~'
|>> (0x7e) is replaced by the Unicode character '˜' (U+02DC SMALL TILDE):
|>>
|>> $ ma
Steffen Nurpmeso wrote in
<20230729002703.lasps%stef...@sdaoden.eu>:
|Chet Ramey wrote in
| <2fd2ed52-3272-3433-6179-164bc5122...@case.edu>:
| ...
||> At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote:
||>> In the bash manual page (`man bash`), the ASCII tilde characte
Denys Vlasenko wrote in
<54f87d1b-e700-e1d3-bf70-400c11145...@redhat.com>:
|IIRC bash used to allow numeric constants of the
|BASE#DIGITS form even if the DIGITS part was empty.
|IOW: not only "64#0", but "64#" too was accepted
|as a valid zero constant.
|
|This no longer works in 5.2.15, pr
Chet Ramey wrote in
:
|On 1/16/23 6:35 PM, Steffen Nurpmeso wrote:
|> It turns out that the inner shell tries to set the process group
|> (to the parent shell which no longer exists), then causing the
|> interactive bash on the terminal to read an EOF next, and without
|> ignor
Hello.
I am sorry to be here again, and it rather is a question than
a bug report. But i thought .. better than not.
On the dash list a FreeBSD programmer reported some problem with
the monitor mode of dash (it turned out a FreeBSD /bin/sh commit
from 2014, ([cd60e2c67d52, sh: Allow enabling job
Andreas Schwab wrote in
<871qo6f90g@igel.home>:
|On Jan 07 2023, Greg Wooledge wrote:
|> The variable l is a modulus, so its largest possible value is 127772.
|> If the code simply said "l = ret % 127773;" then it wouldn't even be
|> an issue. But the % was rewritten, presumably for effic
Chet Ramey wrote in
<30328892-c16b-5007-fee8-4b29430b7...@case.edu>:
|On 1/4/23 12:21 PM, Steffen Nurpmeso wrote:
|> Chet Ramey wrote in
|> <8a61e01d-65c0-6c91-3575-399022fcb...@case.edu>:
|>|On 12/30/22 3:44 PM, Steffen Nurpmeso wrote:
|>|
|>|> D
Chet Ramey wrote in
<8a61e01d-65c0-6c91-3575-399022fcb...@case.edu>:
|On 12/30/22 3:44 PM, Steffen Nurpmeso wrote:
|
|> Digital, logical, liberal, yuck :)
|
|We channeling Supertramp here?
For a nice Breakfast in America, yes.
(Not really that. But really.)
Ciao,
--steff
Robert Elz wrote in
<10111.1672392...@jacaranda.noi.kre.to>:
...
|The way to make this work is to insert sequence points, of which there
|is only one which is plausible in shell arithmetic expressions, and even
|that isn't required to exist by POSIX.
|
| $(( i += i, j += i, i += j ))
|
|
Greg Wooledge wrote in
:
|On Fri, Dec 30, 2022 at 12:21:52AM +0100, Steffen Nurpmeso wrote:
|> ..i want to reiterate the relation to what "human logic" expects.
|
|I'm a human, so I feel qualified to address this point.
|
|What I expect from a command like
|
|(
Andreas Schwab wrote in
<87pmc194i6@igel.home>:
|On Dez 30 2022, Steffen Nurpmeso wrote:
...
|There is no right answer.
But, do you know what?
What you advocate contradicts thousands of years of human culture,
religion and philosophie (to the best of my understanding),
includin
And, lastly (from my side)..
Steffen Nurpmeso wrote in
<20221229231538.pz4j9%stef...@sdaoden.eu>:
...
|Alain D D Williams wrote in
| <20221229215700.gd16...@phcomp.co.uk>:
| ...
||Anyway: back to what the shell should be doing. You cannot put a ';' \
||into (( ))
Ah, wait..
Alain D D Williams wrote in
<20221229215700.gd16...@phcomp.co.uk>:
...
|Anyway: back to what the shell should be doing. You cannot put a ';' \
|into (( ))
|as a sequence point, but the manual does say:
|
|"Sub-expressions in parentheses are evaluated first and may override the
|
Andreas Schwab wrote in
<87358xambe@igel.home>:
|On Dez 29 2022, Alain D D Williams wrote:
|> On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote:
|>
|>> only clang warns on sequencing when tested.
|>
|> Ah: so only clang gives the warning that th
Alain D D Williams wrote in
<20221229215700.gd16...@phcomp.co.uk>:
|On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote:
|> But then shell "operators and their precedence, associativity,
|> and values are the same as in the C language". There are
Alain D D Williams wrote in
<20221229204511.gc16...@phcomp.co.uk>:
...
|No. i += j += i += i does not contain a sequence point so there is \
|no guarantee
|that anything is completed (eg storing a value in variable i) before \
|another
|part (getting a value from variable i) is evaluated.
B
Alain D D Williams wrote in
<20221229173548.gw16...@phcomp.co.uk>:
|On Thu, Dec 29, 2022 at 06:23:09PM +0100, Steffen Nurpmeso wrote:
|> Hello.
|>
|> Name: bash
|> Path: /usr/ports/core
|> Version: 5.2.15
|> Release: 1
|>
Hello.
Name: bash
Path: /usr/ports/core
Version: 5.2.15
Release: 1
$ i=10 j=20;echo $(( i += j += i += j ));echo $i,$j
60
60,50
$ i=10 j=20;echo $(( i += j += i += i ));echo $i,$j
50
50,40
$ cat t.c
#include
int main(void){
int i, j;
Robert Elz wrote in
<16667.1660234...@jacaranda.noi.kre.to>:
|Date:Thu, 11 Aug 2022 16:22:12 +0200
|From: Steffen Nurpmeso
|Message-ID: <20220811142212.jhlpj%stef...@sdaoden.eu>
|
|
|||> Hm. Well i agree that precedence rules which lo
Chet Ramey wrote in
:
|On 8/11/22 10:00 AM, Steffen Nurpmeso wrote:
|.
|> Can you also explain this:
|>
|>$ bash -c ' I1=I2=10 I2=5 I3=I2+=1; echo "<$(( I1*=1?I1:I3 ))>";echo \
|>"<$I1><$I2><$I3>"'
|><
Steffen Nurpmeso wrote in
<20220811140049.avjlp%stef...@sdaoden.eu>:
|Koichi Murase wrote in
| :
||2022年8月11日(木) 9:01 Steffen Nurpmeso :
...
||I think both your version and recent versions of busybox sh are broken.
It was a one line fix.
- while
Greg Wooledge wrote in
:
|On Thu, Aug 11, 2022 at 04:04:57PM +0200, Steffen Nurpmeso wrote:
|> Hm. Well i agree that precedence rules which loose a construct
|> completely (in that =5 is lost in I=5?I:J) is weird, but other
|
|What's that even supposed to *be*? You're a
Robert Elz wrote in
<26517.1660182...@jacaranda.noi.kre.to>:
|I would agree that the values bash is producing don't make a lot
|sense, but I don't think you can say that either is correct - one
|may be more desirable than the other, but that's it.
Hm. Well i agree that precedence rules which
Koichi Murase wrote in
:
|2022年8月11日(木) 9:01 Steffen Nurpmeso :
|> #?0|kent:tmp$ /x/src/busybox.git/busybox sh xxx.sh
|> <6><0><6>
|> <1><1><5>
|
|It seems your busybox interprets« I1=0?I1:I3 » as « (I1=0)?I1:I3 »,
|but this violates POSIX
Hello.
Given this file
# make this work with (ba)sh \
command -v shopt && shopt -s expand_aliases;\
alias p=printf;alias e=echo;alias s=export
s I1=I1=10 I2=5 I3=I2+=1;p "<$((I1=0?I1:I3))>";e "<$I1><$I2><$I3>"
s I1=I1=10 I2=5 I3=I2+=1;p "<$((I1=1?I1:I3))>";e "<$I1><$I2><$I3>"
i now see
Chet Ramey wrote in
:
|On 7/16/22 1:44 PM, Steffen Nurpmeso wrote:
|> I realized there is no unsigned right shift in bash arithmetic
|> expression, and thought maybe there is interest.
|
|Thanks. There aren't any unsigned operators in shell arithmetic now, what
|makes this one ne
Hello.
I realized there is no unsigned right shift in bash arithmetic
expression, and thought maybe there is interest.
This is a not even compile-tested diff against 5.1.16.
(Using same tab/space as in surroundings.)
A nice Sunday i wish everyone.
diff -Napru bash-5.1.orig/expr.c bash-5.1/expr.c
Andreas Schwab wrote in
:
|On Jul 09 2022, Steffen Nurpmeso wrote:
|> $ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I'
|
|The third operand of ?: cannot contain an assignment expression, thus,
|like in C, this is parsed as `(1?(I*=I):I)+=I'.
..
--End of
Ch
Hey,
sorry to come back, but when banging against ?: implementation
i saw this bash 5.1.16 bug:
$ bash -c 'I=3; echo "$((1?(I*=I):(I+=I)))";echo $I'
9
9
$ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I'
bash: line 1: 1?(I*=I):I+=I: attempted assignment to non-variable (error
token is
Well i considered this one done upstream.
Martin D Kealey wrote in
:
|On Sat, 9 Jul 2022, 02:08 Chet Ramey, wrote:
|> On 7/8/22 11:03 AM, Steffen Nurpmeso wrote:
|>
|>> So you seem to use your own itoa, and here is (another) bash bug.
...
|>> In this hindsight bash shoul
Steffen Nurpmeso wrote in
<20220708150300.spmo7%stef...@sdaoden.eu>:
...
|(I post my test -- as of now, i do not yet support ?: --, we
What i meant was "i _could_ post my test".
I mean, it is just a series of nonsense, and not even complete
yet. (In the internet as part of m
1 - 100 of 119 matches
Mail list logo
