Joerg Schilling wrote in <5cd3de0b.BlFpWvouLTKsxKlh%Joerg.Schilling@foku\
s.fraunhofer.de>:
|Steffen Nurpmeso wrote:
|
|> For compatibilities sake i want to add that the subshell version
|> is necessary on Sun OS 5.9, as /usr/xpg4/bin/sh does not support
|> set +o "in a format that is suitabl
Steffen Nurpmeso wrote:
> For compatibilities sake i want to add that the subshell version
> is necessary on Sun OS 5.9, as /usr/xpg4/bin/sh does not support
> set +o "in a format that is suitable for reinput":
I have no 5.9 available anymore, but I can confirm that this works in Solaris
10 or
Robert Elz wrote in <14296.1494903...@andromeda.noi.kre.to>:
|Date:Mon, 15 May 2017 18:36:58 +0200
|From:Steffen Nurpmeso
|Message-ID: <20170515163658.b7ljs%stef...@sdaoden.eu>
|
|| Is it at all possible to store the parameter stack in a variable
|| "x" in order
Stephane Chazelas wrote:
|2017-05-17 13:49:18 +0200, Steffen Nurpmeso:
|[...]
|> vpospar set x 'a \ b' "foo'" "\\'b\\a\\r\\" Aä
|> echo "$#: <${1}><${2}><${3}><$4><$5>"
|> vput vpospar x quote; eval vpospar set ${x}
|> echo $#: <${1}><${2}><${3}><$4><$5>
|[...]
|
|Your problem her
2017-05-17 15:07:26 +0100, Stephane Chazelas:
[...]
> OK, so that would confirm it's a conformance bug in ksh88. ksh93
> would probably have another one in:
>
> ~$ a=a::b: ksh93 -c 'IFS=:; printf "<%s>\n" $a""'
>
> <>
>
> <>### OK
> ~$ a=a::b: ksh93 -c 'IFS=:; printf "<%s>\n" $a${a+""}'
>
>
2017-05-17 14:41:31 +0100, Geoff Clare:
[...]
> Regarding the expansion of $1'' I think the standard is clear that
> if $1 ends with a non-whitespace IFS character, Jilles is right and
> there will be a final empty field. This is because quote removal
> is done after field splitting. For example
Stephane Chazelas wrote, on 17 May 2017:
>
> 2017-05-16 23:39:32 +0200, Jilles Tjoelker:
> [...]
> > This is easily fixed by adding a quoted empty string:
> > set -- $1''
> >
> > If $1 ends with an IFS character, you get a final empty field.
> > If $1 does not end with an IFS character, the empty
2017-05-17 13:49:18 +0200, Steffen Nurpmeso:
[...]
> vpospar set x 'a \ b' "foo'" "\\'b\\a\\r\\" Aä
> echo "$#: <${1}><${2}><${3}><$4><$5>"
> vput vpospar x quote; eval vpospar set ${x}
> echo $#: <${1}><${2}><${3}><$4><$5>
[...]
Your problem here is with your usage of echo. You can't use
Date:Wed, 17 May 2017 10:05:08 +0100
From:Stephane Chazelas
Message-ID: <20170517090508.gb6...@chaz.gmail.com>
| The initial question was about round-tripping "$@", so an
| arbitrary number of arguments.
Ah yes, you're right, it was .. I failed to correctly read
Robert Elz wrote:
|This is the one that in one of the messages I just sent I said
|"not previously posted here" ... When there is a leading/trailing '
|it will be slower...
|
|Aside: to be really correct, without "local" it should really clean up
|the vars (in a trap) in case it is interr
2017-05-17 14:12:28 +0700, Robert Elz:
[...]
> | Depends. If quoting only a handful a arguments, then that call
> | to awk might cost you you a couple of milliseconds indeed. But
> | if processing thousands, you might find that it saves a few
> | seconds.
>
> And if I really had an applica
Date:Wed, 17 May 2017 08:19:24 +0100
From:Stephane Chazelas
Message-ID: <20170517071924.ga6...@chaz.gmail.com>
| 2017-05-16 23:39:32 +0200, Jilles Tjoelker:
| [...]
| > This is easily fixed by adding a quoted empty string:
| > set -- $1''
| Unfortunately, t
2017-05-16 23:39:32 +0200, Jilles Tjoelker:
[...]
> This is easily fixed by adding a quoted empty string:
> set -- $1''
>
> If $1 ends with an IFS character, you get a final empty field.
> If $1 does not end with an IFS character, the empty string does nothing.
[...]
Unfortunately, that doesn't w
Date:Tue, 16 May 2017 17:29:13 +0100
From:Stephane Chazelas
Message-ID: <20170516162913.gd3...@chaz.gmail.com>
| Sorry about that. I hadn't seen that message at the time I
| replied.
No, no problem, it was my fault - I should have not gotten those issues
incorrec
On Tue, May 16, 2017 at 07:41:43AM +0100, Stephane Chazelas wrote:
> 2017-05-16 10:03:56 +0700, Robert Elz:
> > Date:Mon, 15 May 2017 18:36:58 +0200
> > From:Steffen Nurpmeso
> > Message-ID: <20170515163658.b7ljs%stef...@sdaoden.eu>
> [...]
> > Alternatively, you could
2017-05-16 17:33:26 +0700, Robert Elz:
[...]
> | Or just write it as quote() (...) instead of quote() { ...;}
>
> Yes, as you would have seen later, I mentioned that in a subsequent
> message.
Sorry about that. I hadn't seen that message at the time I
replied.
[...]
> | Here, I'd fire awk an
On 5/16/17 6:33 AM, Robert Elz wrote:
> If we start having shell parsing differently depending on what locale the
> user happens to be using, we may as well all give up now, and go find
> something else to do.
Too late:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag
Date:Tue, 16 May 2017 07:41:43 +0100
From:Stephane Chazelas
Message-ID: <20170516064143.ga3...@chaz.gmail.com>
| Or just write it as quote() (...) instead of quote() { ...;}
Yes, as you would have seen later, I mentioned that in a subsequent
message.
| That does
"Schwarz, Konrad" wrote:
|> -Original Message-
|> From: Stephane Chazelas [mailto:stephane.chaze...@gmail.com]
|> To: Robert Elz
|> Cc: Steffen Nurpmeso; austin-group-l@opengroup.org
|> Subject: Re: sh(1): is roundtripping of the positional parameter stack
|
|> Here, I'd fire awk an
> -Original Message-
> From: Stephane Chazelas [mailto:stephane.chaze...@gmail.com]
> To: Robert Elz
> Cc: Steffen Nurpmeso; austin-group-l@opengroup.org
> Subject: Re: sh(1): is roundtripping of the positional parameter stack
> Here, I'd fire awk and quote more than one arg at a time:
>
2017-05-16 10:03:56 +0700, Robert Elz:
[...]
> $ y=$(quote "$x")
[...]
> Just remember to always quote variable references "$x" unless you are
> 100% certain what the content of the variable is, eg: as above with $y
> where we know it is the result of the quote function, so is safe.
[...]
No, the
2017-05-16 10:03:56 +0700, Robert Elz:
> Date:Mon, 15 May 2017 18:36:58 +0200
> From:Steffen Nurpmeso
> Message-ID: <20170515163658.b7ljs%stef...@sdaoden.eu>
[...]
> Alternatively, you could implement this as an external #! script, that
> would be a lot slower, but wou
Date:Tue, 16 May 2017 10:03:56 +0700
From:Robert Elz
Message-ID: <14296.1494903...@andromeda.noi.kre.to>
I keep replying to my own mail. This is really not a good sign!
| Alternatively, you could implement this as an external #! script, that
| would be a lot sl
Date:Tue, 16 May 2017 10:03:56 +0700
From:Robert Elz
Message-ID: <14296.1494903...@andromeda.noi.kre.to>
| Just remember to always quote variable references "$x"
And then I see I forgot in ...
$ stack="$(quote $x):$*"
which is one of the couple where I didn't bot
Date:Mon, 15 May 2017 18:36:58 +0200
From:Steffen Nurpmeso
Message-ID: <20170515163658.b7ljs%stef...@sdaoden.eu>
| Is it at all possible to store the parameter stack in a variable
| "x" in order to restore it exactly "as-is", in the shell?
Yes, it is, you just ne
It is not built in as a standard feature, ($@ has limitations) but it is
plausible to write shell functions that convert the list to CSV format values,
and back, as a "shell only" solution.
On Monday, May 15, 2017 Steffen Nurpmeso wrote:
Hello.
I am wondering whether this is possible in (POSI
Hello.
I am wondering whether this is possible in (POSIX) sh(1)ells, as
an alternative to arrays, so to say, as i just cannot find a way
to achieve it, i always loose the quotes and finally end up where
i do not want to end. Something like this (in the MUA i maintain,
which does not support array
27 matches
Mail list logo