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
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
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 '}'
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
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 --
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
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 "" "" ""; IFS=x; f $*
|
|bash, NetBSD and Fre
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
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
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
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.
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
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] ... | - ]
>
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
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
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
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
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
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"
> >
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
Hi all,
Is there fast way of splitting and joining of strings in the recent Bash
versions?
For splitting, I'm aware of
old="a,b,c"
IFS=, read -a arr <<< "$old"
For joining,
new=$(IFS=,; echo "${arr[*]}")
or
new=$(IFS=,; echo "$*")
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
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
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,
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
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
of IFS whitespace characters is also treated as
|>|> a delimiter.
|>|>
|>|> So this means that *regardless* of whatever $IFS is, the three IFS
|>|> whitespace characters are $IFS anyway *if* that is set to
|>|> a nin-empty non-default value.
|>|
|>|Nonsense.
|>
|> So this means that *regardless* of whatever $IFS is, the three IFS
|> whitespace characters are $IFS anyway *if* that is set to
|> a nin-empty non-default value.
|
|Nonsense.
How you interpret this "also" if not so, that is the question.
My impression was that yo
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
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
whitespace characters is also treated as
|> a delimiter.
|>
|> So this means that *regardless* of whatever $IFS is, the three IFS
|> whitespace characters are $IFS anyway *if* that is set to
|> a nin-empty non-default value.
|
|Nonsense.
How you interpret this "also" if
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,
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
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
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
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
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
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
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
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
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
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>
||
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()
{
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
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.*
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
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 the very dubious
description in its manual page
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
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:
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%
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
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
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
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
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
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.
|>
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
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
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.
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
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
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
> 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
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<>
)
>
> one() { echo "$# 1<$1>"; }
> two() { one "$@"; }
> twox() { one "$@$@"; }
> two
> two x
> twox
> twox x
So... what's the question? You didn't actually ask anything.
As far as I can tell from the bash man page, &qu
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
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
ot;
hobbit:~$ ./foo
list item 0 is <1,2,3,4>
list item 1 is <5,6,7>
Similar packages probably exist in all of the major scripting languages
that are not shells.
I've Cc'ed help-bash for this; that's where the question belongs.
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: $@"
>
ocal job="$1"
> shift
> local a="$1"
> shift
> local b="$1"
> shift
> local remaining="$*"
> echo "Arg1: '$a', Arg2: '$b'"
> }
> process "$data"
>
> 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 question belongs on help-bash, not bug-bash.
--
vq
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"
shift
local remaining="$*"
echo "Arg1: '$a', Arg2: '$b'"
}
process "$dat
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
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
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
> Personally, I think this would be a nice improvement, though it does
> lead to the question "how do you set $XDG_CONFIG_HOME before you read
> bashrc, where environment variables are typically defined".
I was thinking about it the other day. I think defining XDG_CONFIG_HOME a
On 6/2/21 6:46 PM, Eli Schwartz wrote:
The earliest available snapshot in bash's git repo is
bash-1.14.7.tar.gz, at which point ~/.bashrc was already used. This is
in 1994. Someone else might know if it was in use between 1989 and 1994.
The current startup file scheme has been in place since t
t;.
Assuming we don't care about the FHS, but do care about XDG...
This was discussed a month ago in the following thread:
https://lists.gnu.org/archive/html/bug-bash/2021-05/msg00093.html
Personally, I think this would be a nice improvement, though it does
lead to the question "how
Hi.
I would like to know why bash does not follow FHS 3.0 (Filesystem Hierarchy
Standard) suggestions. FHS 3.0 says
"... 3.8.2. Requirements ... If an application needs to create more than one
dot filethen they should be placed in a subdirectory ..."
Bash uses ~/.files instead of ~/.bash/files
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
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
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
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
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
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
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 arithmetic expansion. But if it’s
true why the
On 8/6/20 10:11 AM, Ilkka Virta wrote:
> On 6.8. 15:59, Chet Ramey wrote:
>> On 8/6/20 8:13 AM, Ilkka Virta wrote:
>>> I think they meant the case where all the files matching the given
>>> beginning have a longer prefix in common. The shell expands that prefix to
>>> the command line after asking
On 6.8. 15:59, Chet Ramey wrote:
On 8/6/20 8:13 AM, Ilkka Virta wrote:
I think they meant the case where all the files matching the given
beginning have a longer prefix in common. The shell expands that prefix to
the command line after asking to show all possibilities.
Only if you set the "sho
kups/da would then change into
>> >> $ zz /jidanni_backups/dan_home_bkp with below it the question
>> >> Display all 113 possibilities? (y or n)
>>
>> What happens if you have:
>> dan_home-bkp, dan_home_nobkp, dan-home-bkp, dan-nohome-bkp,
>> dan_nohome-bkp (etc
On Thu, 6 Aug 2020 15:13:30 +0300, Ilkka Virta wrote:
> I think they meant the case where all the files matching the given
> beginning have a longer prefix in common. The shell expands that prefix
> to the command line after asking to show all possibilities.
>
> $ rm *
> $ touch dan_home_bkp{
On 5.8. 22:21, Chris Elvidge wrote:
On 05/08/2020 02:55 pm, Chet Ramey wrote:
On 8/2/20 6:55 PM, 積丹尼 Dan Jacobson wrote:
how about doing the expansion first, so entering
$ zz /jidanni_backups/da would then change into
>> $ zz /jidanni_backups/dan_home_bkp with below it the qu
/jidanni_backups/da would then change into
>> $ zz /jidanni_backups/dan_home_bkp with below it the question
>> Display all 113 possibilities? (y or n)
What happens if you have:
dan_home-bkp, dan_home_nobkp, dan-home-bkp, dan-nohome-bkp,
dan_nohome-bkp (etc.) in /jidanni_backups/?
Which do you ch
anni_backups/da would then change into
> $ zz /jidanni_backups/dan_home_bkp with below it the question
> Display all 113 possibilities? (y or n)
Thanks for the suggestion.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita br
question
Display all 113 possibilities? (y or n)
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
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 samely
describe. but from GNU coreutils 8.22 which ins
On 4/3/18 9:23 PM, yangyajing wrote:
> I don't think it should check for '[:', but it should check if the
> pattern is defined in the charclass even if the pattern does not have a
> multibyte character.
I'll add something so that the code only falls back to the single-byte
matcher if there is a p
I don't think it should check for '[:', but it should check if the
pattern is defined in the charclass even if the pattern does not have a
multibyte character.
when the pattern is one of the character classes defined in the POSIX
standard such as xdigit, these two lines of code can indeed speed
On 4/2/18 10:59 PM, yangyajing wrote:
> Thanks for your reply.
>
> The two lines of code are as follows which in the xstrmatch() function in
> bash-4.3/lib/glob/smatch.c:
>
> if (mbsmbchar (string) == 0 && mbsmbchar (pattern) == 0)
> return (internal_strmatch ((unsigned char *)pattern, (un
1 - 100 of 449 matches
Mail list logo
