Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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. I did not know

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

On 9/19/24 2:42 AM, Robert Elz wrote: Date:Thu, 19 Sep 2024 00:45:44 +0200 From:Steffen Nurpmeso Message-ID: <20240918224544.aXWgbZu-@steffen%sdaoden.eu> | Woops. I did not know that, i always separate {} at the beginning | an the end, yet not (). '(' and

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

Date:Thu, 19 Sep 2024 00:45:44 +0200 From:Steffen Nurpmeso Message-ID: <20240918224544.aXWgbZu-@steffen%sdaoden.eu> | Woops. I did not know that, i always separate {} at the beginning | an the end, yet not (). '(' and ')' (parentheses) are operators, '{' and '}'

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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 || separating w

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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 | separating whitespace in between the ; and the } which closes the | function --

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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 ksh88 all agree and print 2. pdksh |> prints 3 but

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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 "" "" ""; IFS=x; f $* | |bash, NetBSD and Fre

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

Date:Wed, 18 Sep 2024 07:21:30 -0400 From:Greg Wooledge Message-ID: | 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 pri

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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 ksh88 all agree and print 2. pdksh prints 3 but mksh and oksh print 1. dash, ksh93, yash, and zsh pri

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

On Wed, Sep 18, 2024 at 08:05:10 +0300, 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 ksh88 all agree and print 2. pdksh > prints 3 but mksh and oksh print

Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)

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 ksh88 all agree and print 2. pdksh prints 3 but mksh and oksh print 1. dash, ksh93, yash, and zsh print 0.

Re: (question) fast split/join of strings

cool .. gotta do .. thxx n greets .. On Tuesday, September 17, 2024, Greg Wooledge wrote: > On Tue, Sep 17, 2024 at 17:00:16 +0200, alex xmb sw ratchev wrote: > > plz what does 'local -' do , its newer to me > > i forgot all about it already > >local [option] [name[=value] ... | - ] >

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 17:00:16 +0200, alex xmb sw ratchev wrote: > plz what does 'local -' do , its newer to me > i forgot all about it already local [option] [name[=value] ... | - ] For each argument, a local variable named name is created, and assigned valu

Re: (question) fast split/join of strings

very respectable great email mate the set -f , ye i always missed it i gotta train me that more in the 1,2,,3 issue , id say thata valid cause ,, is literarly an empty field a second sep seems me great just as awk , one sep is for fields on a line , one is the per line sep set -f ; ss=$'\1\2' ss

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 16:07:58 +0200, alex xmb sw ratchev wrote: > savedifs=${IFS@A} savedifs=${savedifs:- unset -v IFS } > str=1,2,3 IFS=, arr=( $str ) joined=${arr[*]} > eval "$savedifs" Using unquoted $str in an array expansion to do the splitting has a couple drawbacks: 1) Globbing (filenam

Re: (question) fast split/join of strings

in the printf to stdout a final printf \\n is missing greets On Tuesday, September 17, 2024, alex xmb sw ratchev wrote: > savedifs=${IFS@A} savedifs=${savedifs:- unset -v IFS } > str=1,2,3 IFS=, arr=( $str ) joined=${arr[*]} > eval "$savedifs" > > alternative middleline > > sep=, str=1$sep2$sep

Re: (question) fast split/join of strings

savedifs=${IFS@A} savedifs=${savedifs:- unset -v IFS } str=1,2,3 IFS=, arr=( $str ) joined=${arr[*]} eval "$savedifs" alternative middleline sep=, str=1$sep2$sep3 IFS=$sep arr=( $str ) joined=${arr[*]} ( at var=assignment , quotes dont matter , excepts to bind spaced code together as cmd or cmd

Re: (question) fast split/join of strings

On Tue, Sep 17, 2024 at 02:56:05 -0400, Lawrence Velázquez wrote: > This question is more appropriate for help-bash than bug-bash. > > On Tue, Sep 17, 2024, at 2:21 AM, William Park wrote: > > For splitting, I'm aware of > > old="a,b,c" > > IFS=, read -a arr <<< "$old"

Re: (question) fast split/join of strings

This question is more appropriate for help-bash than bug-bash. On Tue, Sep 17, 2024, at 2:21 AM, William Park wrote: > Hi all, > > Is there fast way of splitting and joining of strings in the recent Bash > versions? Define "fast". > For splitting, I'm aware of > old="a,b,c" > IFS=, re

Re: Question on $@ vs $@$@

Dear Robert, i am totally distracted regarding this topic. I will carefully read it and the standard again. (We also have likely the last midsommer week here, and i am out whenever i can.) Thanks for taking the time to look that deeply into this issue. Robert Elz wrote in <12813.1724902...@jacara

Re: Question on $@ vs $@$@

On 8/28/24 11:41 PM, Robert Elz wrote: The reason all this is messy, is that it is (more or less) the way it was implemented in the original Bourne shell. That tells you that the implementation must be simple - the rules might seem complex to explain, but the implementation is sure to be simpl

Re: Question on $@ vs $@$@

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. skip leading whitespace anyhow (IFS or not,

Re: Question on $@ vs $@$@

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 IFS whitespace || char

Re: Question on $@ vs $@$@

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 IFS whitespace | characters are then ignored. Not quite. Any sequence of any amount of IFS

Re: Question on $@ vs $@$@

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 newline are ignored at the |>|

Re: Question on $@ vs $@$@

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 newline are ignored at the |> beginning and end of the word,

Re: Question on $@ vs $@$@

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'd |be better off with somet

Re: Question on $@ vs $@$@

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

Re: Question on $@ vs $@$@

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 |> character is in the

Re: Question on $@ vs $@$@

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 my MUA does,

Re: Question on $@ vs $@$@

try ${@@Q} and ${*@Q} greets On Wed, Aug 14, 2024, 2:45 AM Steffen Nurpmeso wrote: > 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() withou

Re: Question on $@ vs $@$@

On 8/24/24 11:49 PM, Lawrence Velázquez wrote: The bash manual says [1]: * ($*) Expands to the positional parameters, starting from one. When the expansion is not within double quotes, each positional parameter expands to a

Re: Question on $@ vs $@$@

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 character is in the value of IFS (an IFS whitespace cha

Re: Question on $@ vs $@$@

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 my MUA does, | namely resolving $* as a single string first, does not happen, | right? That's

Re: Question on $@ vs $@$@

On Sat, Aug 24, 2024, at 11:49 PM, Lawrence Velázquez wrote: > Correct. Since you're using $* unquoted in a context where field > splitting is performed, the shell does not expand it to a single > field. That is, unless there's a single positional parameter that is not further split. -- vq

Re: Question on $@ vs $@$@

On Sat, Aug 24, 2024, at 10:08 PM, Steffen Nurpmeso wrote: > One hopefully last thing in this regard for me, > > c() { echo "$# 1<$1> 2<$2> 3<$3> *<$*> @<$@>"; } This easily obfuscates the structure of the "$@" expansion. You'd be better off with something like this, which prints each positiona

Re: Question on $@ vs $@$@

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 definition of IFS whi

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

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.* --End of --steffen | |De

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

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() { |> echo $#,1=$1,2

Re: Question on $@ vs $@$@

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@steffen%sdaoden.eu> ||

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

Date:Sat, 24 Aug 2024 02:33:26 +0200 From:Emanuele Torre Message-ID: | No. It is working correctly. It is indeed. | This $1 is unquoted, it will be split. You need to use "$1" if you don't | want it to split. Alternatively, make a() be a() {

Re: Question on $@ vs $@$@

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 definition of IFS whitespace. | So this "adjacent" even if *not* part of $IFS. No, only cha

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

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 *Sigh.*

Re: Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

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() { > echo $#,1=$1,2=$2,"$*",$*, This $1 is unquoted, it will b

Question on differences on quoted $* (Was: Re: Question on $@ vs $@$@)

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 "$*"$*

Re: Question on $@ vs $@$@

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 the very dubious description in its manual page

Re: Question on $@ vs $@$@

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 $* "$*"; Your printing function "a" is highly questionable. It's got unquoted word expansions that'll do who knows what, and it's also usin

Re: Question on $@ vs $@$@

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>: |||Date:

Re: Question on $@ vs $@$@

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.t6-hdjZT@steffen%

Re: Question on $@ vs $@$@

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 see word split || dif

Re: Question on $@ vs $@$@

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 see word split | differences. There are so many problems with this test, that I'm not sure it is worth

Re: Question on $@ vs $@$@

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-124854793...@case.edu>: |||On

Re: Question on $@ vs $@$@

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-bash even though i thi

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 09:23:49AM -0400, Greg Wooledge wrote: > The most obvious would be to treat "$@$@" as if it were "$@" "$@", > generating exactly two words for each positional parameter. > > Thanks for this. My two cents: if I want "$@" "$@", i write it litterally. "$@$@" kinda

Re: Question on $@ vs $@$@

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 listening, so, thus. |>

Re: Question on $@ vs $@$@

On 8/13/24 8:45 PM, Steffen Nurpmeso wrote: 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

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 17:58:15 +0300, Oğuz wrote: > On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > > However, as ksh93 makes "" from this > > expansion, and so probably ksh88 might have done as well > > No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0. HP-UX 10.20 a

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 5:23 PM Robert Elz wrote: > However, as ksh93 makes "" from this > expansion, and so probably ksh88 might have done as well No, both Sun and SCO variants expand "$@$@" to zero fields when $# is 0.

Re: Question on $@ vs $@$@

Date:Wed, 14 Aug 2024 09:23:49 -0400 From:Greg Wooledge Message-ID: | The most obvious would be to treat "$@$@" as if it were "$@" "$@", That would clearly be wrong when there are positional parameters. | As a human trying to read this expression and figure out

Re: Question on $@ vs $@$@

Date:Wed, 14 Aug 2024 11:04:08 +0200 From:Marc Chantreux Message-ID: | I'm really currious: do you see another one ? The case he was asking about is when $# is 0 (no positional params set) and whether "$@$@" should result in "" (1 arg) or nothing (0 args). Upon r

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 11:04:08 +0200, Marc Chantreux wrote: > > We know what "$@" is supposed to do. And something like "x${@}y" is > > well-defined also -- you simply prefix "x" to the first word, and append > > "y" to the final word. > > > But I don't know how "$@$@" is supposed to be interpr

Re: Question on $@ vs $@$@

> We know what "$@" is supposed to do. And something like "x${@}y" is > well-defined also -- you simply prefix "x" to the first word, and append > "y" to the final word. > But I don't know how "$@$@" is supposed to be interpreted. I do not see > anything in the official wording that explains how

Re: Question on $@ vs $@$@

On Wednesday, August 14, 2024, Steffen Nurpmeso wrote: > > one() { echo "$# 1<$1>"; } > two() { one "$@"; } > twox() { one "$@$@"; } > two > two x > twox > twox x > $ dash shbug.sh > 0 1<> > 1 1 > 1 1<> > 1 1 > #?0|kent:tmp$ bash shbug.sh > 0 1<> > 1 1 > 0 1<>

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024 at 02:45:25 +0200, Steffen Nurpmeso wrote: > 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

Re: Question on $@ vs $@$@

On Wed, Aug 14, 2024, 02:45 Steffen Nurpmeso wrote: > 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

Re: Question that baffles AI (all of them)

On Sat, Jun 15, 2024 at 05:30:17PM -0400, Saint Michael wrote: > in this code: > data="'1,2,3,4','5,6,7,8'" > how can I get my (a) and (b) arguments right? > The length of both strings is unpredictable. > a="1,2,3,4" and b="5,6,7,8"" This is a parsing problem. Bash is not a particularly good cho

Re: Question that baffles AI (all of them)

bash dat.sh.1 1,2,3,4 a 1 , b 2 a 3 , b 4 or u meant to equally split the args ? On Sat, Jun 15, 2024, 11:30 PM Saint Michael wrote: > in this code: > data="'1,2,3,4','5,6,7,8'" > > # Define the processing function > process() { > echo "There are $# arguments." > echo "They are: $@" >

Re: Question that baffles AI (all of them)

On Sat, Jun 15, 2024, at 5:30 PM, Saint Michael wrote: > in this code: > data="'1,2,3,4','5,6,7,8'" > > # Define the processing function > process() { > echo "There are $# arguments." > echo "They are: $@" > local job="$1" > shift > local a="$1" > shift > local b="$1" >

Re: Question about monitor mode / ignoreeof / EOF read

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 |> ignoreeof set the in

Re: Question about monitor mode / ignoreeof / EOF read

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 ignoreeof set the interactive shell then exits. (This hap

Re: Question about case statement in Bash docs

On 5/10/21 10:40 AM, Andreas Schwab wrote: On Mai 10 2021, Chet Ramey wrote: Either way, quote removal happens, the double quotes are removed, and the characters between the double quotes are treated specially. POSIX doesn't mention quote removal either. Is that a bug? There is the parenthe

Re: Question about case statement in Bash docs

On Mai 10 2021, Chet Ramey wrote: > Either way, quote removal happens, the double quotes are removed, and > the characters between the double quotes are treated specially. POSIX doesn't mention quote removal either. Is that a bug? There is the parenthetical remark "(which also describes the eff

Re: Question about case statement in Bash docs

On 5/10/21 10:23 AM, Andreas Schwab wrote: On Mai 10 2021, Greg Wooledge wrote: On Mon, May 10, 2021 at 09:12:33PM +1000, AlvinSeville7cf wrote: x=test case $x in "test") echo Y esac Pattern is quoted but no quote removal is performed according to docs. Quote removal

Re: Question about case statement in Bash docs

On Mai 10 2021, Greg Wooledge wrote: > On Mon, May 10, 2021 at 09:12:33PM +1000, AlvinSeville7cf wrote: >>x=test >>case $x in >>"test") echo Y >>esac >> >>Pattern is quoted but no quote removal is performed according to docs. > > Quote removal is essential, because of the

Re: Question about case statement in Bash docs

On 5/10/21 7:12 AM, AlvinSeville7cf wrote: Hello! Let’s consider the following snippet from [1]Bash docs: case word in [ [(] pattern [| pattern]…) command-list ;;]… esac It is written that: Each pattern undergoes tilde expansion, parameter expansion, command substitution, and a

Re: Question about case statement in Bash docs

On Mon, May 10, 2021 at 09:12:33PM +1000, AlvinSeville7cf wrote: >x=test >case $x in >"test") echo Y >esac > >Pattern is quoted but no quote removal is performed according to docs. Quote removal is essential, because of the way the empty string is matched: case $foo in

Re: Question about help information for the printf command

On 9/9/19 10:45 PM, 2477441814 wrote: > Dear team, > > > when I invoke 'help printf' in terminal to view help manual, It shown me '%b > %q %(fmt)T' is an addition to printf(1) and printf(3), The online version of > bash manual from (http://www.gnu.org/software/bash/manual/bash.html) does > sam

Re: question on retrieving map(-A) value w/indirect name

On Fri, Mar 16, 2018 at 05:50:04PM -0700, L A Walsh wrote: > If I have assoc-array: > > declare -A foo=([one]=11 [two]=22) > > and am passing name in another var, like "fee" > > fee=foo > > I tried echoing the val: > > echo ${!fee[one]} > > but got nothing -- tried a few other syntaxes. 1

Re: question on retrieving map(-A) value w/indirect name

David Margerison wrote: processSrvState() { local cur_up="$1[cur_up]" local max_up="$1[max_up]" if [[ "${!cur_up}" == "${!max_up}" ]] ; then echo ok fi } declare -A foo=([cur_up]=11 [max_up]=11) processSrvState foo # note that the array name must not conflict with any keys Th

Re: question on retrieving map(-A) value w/indirect name

On 17 March 2018 at 20:40, L A Walsh wrote: > > I seebut that begs the question, how do you access an array's > members using a var holding the array's name? > > I wanted to be able to do something like have a set of > values in an assoc. map, and pass the name to a generic > processing routin

Re: question on retrieving map(-A) value w/indirect name

On 17 March 2018 at 11:50, L A Walsh wrote: > > I'm a bit confused ... > If I have assoc-array: > > declare -A foo=([one]=11 [two]=22) > > and am passing name in another var, like "fee" > > fee=foo > > I tried echoing the val: > > echo ${!fee[one]} > > but got nothing -- tried a few other synta

Re: question on retrieving map(-A) value w/indirect name

Chet Ramey wrote: On 3/16/18 8:50 PM, L A Walsh wrote: I'm a bit confused ... If I have assoc-array: declare -A foo=([one]=11 [two]=22) and am passing name in another var, like "fee" fee=foo I tried echoing the val: echo ${!fee[one]} but got nothing -- tried a few other syntaxes.

Re: question on retrieving map(-A) value w/indirect name

On 3/16/18 8:50 PM, L A Walsh wrote: > > I'm a bit confused ... > If I have assoc-array: > >  declare -A foo=([one]=11 [two]=22) > > and am passing name in another var, like "fee" > >  fee=foo > > I tried echoing the val: > >  echo ${!fee[one]} > > but got nothing -- tried a few other syntax

Re: (OffTopic,) Gnu-Environment restrictions (was Re: Question )

Robert Elz wrote: > I will send one more reply on this topic - I am replying to this message > as I agree with the change of Subject - this is off topic for this list, > which is why I will not respond any further to messages about this here. You are most enlightened and I will do the same with th

Re: (OffTopic,) Gnu-Environment restrictions (was Re: Question )

I will send one more reply on this topic - I am replying to this message as I agree with the change of Subject - this is off topic for this list, which is why I will not respond any further to messages about this here. Bob Proulx said (in a message with the original subject): | Many people in

(OffTopic,) Gnu-Environment restrictions (was Re: Question )

Bob Proulx wrote: Robert Elz wrote: But any restrictions on the recipient mean that the software is not really free, and that includes nonsense like requiring users to redistribute the sources to anyone who wants it. That's not freedom, that's an obligation (serfdom - you have to do my work

Re: Question

Robert Elz wrote: > Bob Proulx wrote: > > However this difference in philosophy does not change the technology > > that creating a compiler for an interpreted language is very hard. > > Maybe impossible. > > No. Not impossible, not even all that difficult, just in this case, > not all that benefi

Re: Question

On 9/16/17 11:16 PM, Robert Elz wrote: > Now to the philosophical ... I agree with the aims of free software, but > I believe that should be interpreted correctly - that is, if software is > free, it should impose no restrictions at all upon is recipients, which > includes hidden "you should recip

Re: Question

Date:Thu, 14 Sep 2017 20:22:04 -0600 From:Bob Proulx Message-ID: <20170914195843892632...@bob.proulx.com> | However this difference in philosophy does not change the technology | that creating a compiler for an interpreted language is very hard. | Maybe impossib

Re: Question

Saint Michael wrote: > I use Linux. My business to provide services for problems that I solve, as > you mention, by calling Awk, sed, join, etc., and databases. Sounds good. I classify myself the same way. :-) > I allow my customers to login to a box that I provide in my > datacenter. I cannot a

Re: Question

Dear Bob I use Linux. My business to provide services for problems that I solve, as you mention, by calling Awk, sed, join, etc., and databases. I allow my customers to login to a box that I provide in my datacenter. I cannot accept that it is impossible to restrict them to only call my *,sh script

Re: Question

Saint Michael wrote: > Dear Maintainer Note that I am not the maintainer. > Is there a commercial or free software that can take a Bash script and > transparently turn it into a C executable, provided the machines where it > runs has any of the external commands like awk, etc? Not as far as I am

Re: Question about arithmetic expression grammar

On 10/10/16 9:57 AM, Stephane Chazelas wrote: > Now, if we look at the C spec, the way +++ is parsed is down to > tokenisation that will also go for the longest operator first. > > There --test+++3 would be tokenised as -- test ++ + 3 which > would lead to a syntax error as test++ isn't an lvalue

Re: Question about arithmetic expression grammar

2016-10-08 17:33:00 +0200, Conrad Hoffmann: [...] > $ TEST=5; echo $((--TEST+++3)) # outputs 7 > > However, due to the documented operator precedence, I would have > expected that expression to be equal to: > > $ TEST=5; echo $((--(TEST++)+3)) # outputs 8 > > Instead, though, it seems to be

Re: Question: is this a bug in BASh (pre-exec trap)

On 9/9/16 2:00 PM, Matthew Giassa wrote: > Good day, > > I've been doing some testing with the bash-prexec script which uses a > DEBUG trap to issue user-supplied functions before executing each > command (https://github.com/rcaloras/bash-preexec). > > Here is a minimal working example > (https:

Re: question of command cd's option [-e]

DJ Mills writes: > -e is only used with -P, so the current synopsis makes more sense and is > clearer, IMO. You can use -e also with -L, it just doesn't have an effect. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "

Re: question of command cd's option [-e]

On Tue, Jan 15, 2013 at 9:19 AM, Andreas Schwab wrote: > I'd also suggest to simplify the synopsis. > > cd [-LPe] [dir] > > Andreas. > > > -e is only used with -P, so the current synopsis makes more sense and is clearer, IMO. DJ

Re: question of command cd's option [-e]

I'd also suggest to simplify the synopsis. cd [-LPe] [dir] Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."

Re: question of command cd's option [-e]

On 1/14/13 9:20 PM, MaShimiao wrote: > Bash Version: 4.2 > Patch Level: 28 > Release Status: release > > Description: > > I want to use the option [-e] of command cd. But I found I can't use. Thanks for the report, good catch. This will be fixed in the next release. Chet -- ``The lyf so sho

  1   2   >