Re: Feature Request: scanf-like parsing
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı: > On 1/25/21 12:58 PM, Oğuz wrote: > > I rarely use eval, but when I do, it works just fine. >> > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. > Heh. Made it my avatar > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > -- Oğuz
Re: Feature Request: scanf-like parsing
On 1/26/21 2:46 AM, Chet Ramey wrote: > On 1/25/21 12:58 PM, Oğuz wrote: >> I rarely use eval, but when I do, it works just fine. > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. Not sure whether attachments are allowed... If not this link will work for some length of time: https://4e4.win/basheval.jpg :-D Peter
Re: Feature Request: scanf-like parsing
On 1/25/21 2:51 PM, Greg Wooledge wrote: On Mon, Jan 25, 2021 at 02:46:24PM -0500, Chet Ramey wrote: On 1/25/21 12:58 PM, Oğuz wrote: I rarely use eval, but when I do, it works just fine. Someone should create a meme with this text superimposed on an image of the Dos Equis most interesting man in the world. https://imgflip.com/i/4v9jun Oh, look, little Bobby Tables is back. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021 at 02:46:24PM -0500, Chet Ramey wrote: > On 1/25/21 12:58 PM, Oğuz wrote: > > > I rarely use eval, but when I do, it works just fine. > > Someone should create a meme with this text superimposed on an image of the > Dos Equis most interesting man in the world. https://imgflip.com/i/4v9jun
Re: Feature Request: scanf-like parsing
On 1/25/21 12:58 PM, Oğuz wrote: I rarely use eval, but when I do, it works just fine. Someone should create a meme with this text superimposed on an image of the Dos Equis most interesting man in the world. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 1/25/21 12:53 PM, Greg Wooledge wrote:
On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote:
This is good advice. If the double-quoting the @K transformation performs
is not what you need, use the @Q transformation to get something closer.
Those don't do the same thing, though.
Yes, you'll have to to use something like "${!aa[@]}" to get the array keys
and either serialize assignment or construct a new compound assignment.
But my point is the double-quoting (or $'...' quoting) the @K
transformation performs should be good enough for most common uses, and if
you need something else you'll have to do some work.
I must say that the way @K works is surprising. I would have expected
it to expand to a list of multiple strings (the way "$@" does, and without
the internal quoting). I guess it's designed to support the new
name=( key1 value1 key2 value2 ...) syntax, which I haven't used yet,
so I don't know where all the sharp edges are.
The analog is the @A transformation, which also expands to a single string.
It should be quoted enough to survive `eval', unless you're dogmatic about
not using that.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
Le 25/01/2021 à 18:58, Oğuz écrivait : I rarely use eval, but when I do, it works just fine. I can't really agree with the sentiment of your article, sorry. I use eval when I am sure there is no other safer way. Mean, if I can achieve the same with declare foo="dynamically generated content" I opt for the later, like mapping a whole file into an associative array in one go instead of iterating incrementing the array line by line. Because I know it can be done for a declare and the content is generated with printf %q or jq's @sh filter. Anyway on systems where there is a sufficiently advanced Bash available for these nice advanced bashisms, There are probably better all-purpose scripting languages available as well like Python or Perl. For obsolete closed-source systems where I don't have control on if a decent Bash version is available, using the nice Bash feature is not an option anyway, and sometimes, yes eval will help. -- Léa Gris
Re: Feature Request: scanf-like parsing
word, hopefully ppl migrate to such as 'use what a tool supports' On Mon, Jan 25, 2021, 19:22 Oğuz wrote: > On Mon, Jan 25, 2021 at 9:15 PM Greg Wooledge wrote: > > > Again, there are many different authors of that page. Think of it as > > a community FAQ, rather than mine. It was written by a committee, as > > horrifying as that may sound. > > > > Okay, I'm not saying I know better than the members of that ``committee'', > it's just that I find it difficult to concur with the conclusion they > reached. I don't think eval should be avoided. >
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021 at 9:15 PM Greg Wooledge wrote: > Again, there are many different authors of that page. Think of it as > a community FAQ, rather than mine. It was written by a committee, as > horrifying as that may sound. > Okay, I'm not saying I know better than the members of that ``committee'', it's just that I find it difficult to concur with the conclusion they reached. I don't think eval should be avoided.
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021 at 08:58:23PM +0300, Oğuz wrote: > This sentence alone reflects that article's perspective on the issue. > > "eval" is a common misspelling of "evil". > > I rarely use eval, but when I do, it works just fine. I can't really agree > with the sentiment of your article, sorry. Again, there are many different authors of that page. Think of it as a community FAQ, rather than mine. It was written by a committee, as horrifying as that may sound.
Re: Feature Request: scanf-like parsing
assoc copy without eval
root@localhost:~# unset orig copy
root@localhost:~# declare -A orig=( [a\ key]=a\ value [another\
key]=another\ value ) ; rep=$( declare -p orig )
root@localhost:~# rep=$( declare -p orig )
root@localhost:~# declare -A "copy=${rep#*=}"
root@localhost:~# declare -p copy
declare -A copy=(["another key"]="another value" ["a key"]="a value" )
root@localhost:~#
On Mon, Jan 25, 2021, 18:53 Greg Wooledge wrote:
> On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote:
> > This is good advice. If the double-quoting the @K transformation performs
> > is not what you need, use the @Q transformation to get something closer.
>
> Those don't do the same thing, though.
>
> unicorn:~$ declare -A aa=([a key]="a value" [$'\n\nx\n']=foo)
> unicorn:~$ printf %s\\n "${aa[@]@K}"
> "a key" "a value" $'\n\nx\n' "foo"
> unicorn:~$ printf %s\\n "${aa[@]@Q}"
> 'a value'
> 'foo'
>
> One gives both keys and values in a single string, while the other gives
> only values (but as multiple strings).
>
> I must say that the way @K works is surprising. I would have expected
> it to expand to a list of multiple strings (the way "$@" does, and without
> the internal quoting). I guess it's designed to support the new
> name=( key1 value1 key2 value2 ...) syntax, which I haven't used yet,
> so I don't know where all the sharp edges are.
>
> ... thinking ...
>
> It looks like @K serializes an indexed or associative array's contents
> into a string. That's a useful operation for sure. It allows you to
> do things like export an array through the environment and reconstruct
> it in a child process, albeit not seamlessly.
>
> Previously, I've seen people try to write hacks to do this by taking
> the output of "declare -p myarray" and stripping off the part up to
> and including the array's name. @K is a much cleaner way, as it gives
> just the contents, not the variable's name or flags.
>
> It's still surprising, though, which means it'll probably show up on
> my FAQ at some point, whenever people start trying to use it.
>
>
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021 at 8:06 PM Greg Wooledge wrote: > It's a tricky thing to deal with. Eli referenced my wiki, which has a > page dedicated to it, with contributions from many different authors. > The resulting quasi-consensus is complex and perhaps even a little > bit self-contradictory as a result. This sentence alone reflects that article's perspective on the issue. > "eval" is a common misspelling of "evil". I rarely use eval, but when I do, it works just fine. I can't really agree with the sentiment of your article, sorry.
Re: Feature Request: scanf-like parsing
On 1/25/21 12:48 PM, Alex fxmbsw7 Ratchev wrote: you havent been on #bash freenode irc where it is the reverse to this quote 'no one ..', where also 'bash is no coding language' and x other invalid things are common, to all i disagree, but the masses of ignorant wrong teachen ppl overwealth me and i mostly left I'm fairly positive we've crossed paths on #bash, numerous times. I'm not sure when I joined, exactly, but my current logs go back about 2 years. I know exactly what you're talking about, and you're misrepresenting it. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021 at 12:13:25PM -0500, Chet Ramey wrote:
> This is good advice. If the double-quoting the @K transformation performs
> is not what you need, use the @Q transformation to get something closer.
Those don't do the same thing, though.
unicorn:~$ declare -A aa=([a key]="a value" [$'\n\nx\n']=foo)
unicorn:~$ printf %s\\n "${aa[@]@K}"
"a key" "a value" $'\n\nx\n' "foo"
unicorn:~$ printf %s\\n "${aa[@]@Q}"
'a value'
'foo'
One gives both keys and values in a single string, while the other gives
only values (but as multiple strings).
I must say that the way @K works is surprising. I would have expected
it to expand to a list of multiple strings (the way "$@" does, and without
the internal quoting). I guess it's designed to support the new
name=( key1 value1 key2 value2 ...) syntax, which I haven't used yet,
so I don't know where all the sharp edges are.
... thinking ...
It looks like @K serializes an indexed or associative array's contents
into a string. That's a useful operation for sure. It allows you to
do things like export an array through the environment and reconstruct
it in a child process, albeit not seamlessly.
Previously, I've seen people try to write hacks to do this by taking
the output of "declare -p myarray" and stripping off the part up to
and including the array's name. @K is a much cleaner way, as it gives
just the contents, not the variable's name or flags.
It's still surprising, though, which means it'll probably show up on
my FAQ at some point, whenever people start trying to use it.
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021, 17:50 Eli Schwartz wrote: > On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: > > cool, now that u're the main bash coder greycat and co wont fall like > > cannibals over you for using eval > > cheers for old code > > No one ever said eval is evil, if you're using it solely to consume the > output of a shell builtin functionality specifically designed to produce > eval-safe text. > you havent been on #bash freenode irc where it is the reverse to this quote 'no one ..', where also 'bash is no coding language' and x other invalid things are common, to all i disagree, but the masses of ignorant wrong teachen ppl overwealth me and i mostly left eval is evil, alias dont work in scripts, x x x .. common stupidity against my will In fact, greycat's official stance on precisely that can be found here > (and agrees that Chet's example is reasonable and correct): > https://mywiki.wooledge.org/BashFAQ/048#Examples_of_good_use_of_eval > > Opinions differ on whether it's evil to try writing your own text for > eval'ing, since most people doing so seem to get it wrong. But that's > neither here nor there. > > -- > Eli Schwartz > Arch Linux Bug Wrangler and Trusted User > >
Re: Feature Request: scanf-like parsing
On 1/25/21 11:59 AM, Greg Wooledge wrote: The problem with eval is that for every OK usage, there are a thousand incorrect and dangerous uses. Avoid those, by being absolutely sure you know what you're doing, and why you're doing it. The shell is a sharp tool. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 1/25/21 11:59 AM, Greg Wooledge wrote: The problem with eval is that for every OK usage, there are a thousand incorrect and dangerous uses. Avoid those, by being absolutely sure you know what you're doing, and why you're doing it. This is good advice. If the double-quoting the @K transformation performs is not what you need, use the @Q transformation to get something closer. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 1/25/21 11:59 AM, Greg Wooledge wrote:
On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote:
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
declare -A copy
eval copy=( "${assoc[@]@K}" )
So many reputable people contributed to the demonization of `eval' that I
don't think I can convince anyone that there's nothing wrong with it
anymore.
It's a tricky thing to deal with. Eli referenced my wiki, which has a
page dedicated to it, with contributions from many different authors.
The resulting quasi-consensus is complex and perhaps even a little
bit self-contradictory as a result.
You'll want to use eval only when it's absolutely necessary, and only when
it's safe. If bash's @K feature is designed to be fed to eval, then we
can assume it's safe. It becomes one of the very small number of
green-lighted cases where eval is OK.
The problem with eval is that for every OK usage, there are a thousand
incorrect and dangerous uses. Avoid those, by being absolutely sure
you know what you're doing, and why you're doing it.
And it's also worth systematically creating alternatives for all the
safe and legitimate uses of "eval" so that eventually the whole
mechanism can be discouraged without having to rely on the nuance you've
just described.
Re: Feature Request: scanf-like parsing
On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote:
> 25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
> > declare -A copy
> > eval copy=( "${assoc[@]@K}" )
>
> So many reputable people contributed to the demonization of `eval' that I
> don't think I can convince anyone that there's nothing wrong with it
> anymore.
It's a tricky thing to deal with. Eli referenced my wiki, which has a
page dedicated to it, with contributions from many different authors.
The resulting quasi-consensus is complex and perhaps even a little
bit self-contradictory as a result.
You'll want to use eval only when it's absolutely necessary, and only when
it's safe. If bash's @K feature is designed to be fed to eval, then we
can assume it's safe. It becomes one of the very small number of
green-lighted cases where eval is OK.
The problem with eval is that for every OK usage, there are a thousand
incorrect and dangerous uses. Avoid those, by being absolutely sure
you know what you're doing, and why you're doing it.
Re: Feature Request: scanf-like parsing
On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: cool, now that u're the main bash coder greycat and co wont fall like cannibals over you for using eval cheers for old code No one ever said eval is evil, if you're using it solely to consume the output of a shell builtin functionality specifically designed to produce eval-safe text. In fact, greycat's official stance on precisely that can be found here (and agrees that Chet's example is reasonable and correct): https://mywiki.wooledge.org/BashFAQ/048#Examples_of_good_use_of_eval Opinions differ on whether it's evil to try writing your own text for eval'ing, since most people doing so seem to get it wrong. But that's neither here nor there. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: Feature Request: scanf-like parsing
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
>
> There has been code to do this for a long time. It's currently tagged for
> bash-5.2. If you want to play around with it, look in subst.c for
> shouldexp_replacement and its caller, and uncomment them. You'll have to
> wait for the next devel branch push for a version that works with multibyte
> characters -- that should tell you how long it's been there.
>
Great, thanks!
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
>
> I forgot to mention that since the keys and values are both quoted so they
> can be reused, you can copy an associative array using a key-value
> assignment like
>
> declare -A copy
> eval copy=( "${assoc[@]@K}" )
So many reputable people contributed to the demonization of `eval' that I
don't think I can convince anyone that there's nothing wrong with it
anymore.
--
Oğuz
Re: Feature Request: scanf-like parsing
i completly agree, .. just dunno why others dont :) On Mon, Jan 25, 2021, 17:31 Chet Ramey wrote: > On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: > > cool, now that u're the main bash coder greycat and co wont fall like > > cannibals over you for using eval > > cheers for old code > > The shell is a sharp tool. If you're going to use it to try and cut your > fingers off, it's not going to stop you. If you use it with care, you can > usually accomplish what you need. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: Feature Request: scanf-like parsing
On 1/25/21 11:28 AM, Alex fxmbsw7 Ratchev wrote: cool, now that u're the main bash coder greycat and co wont fall like cannibals over you for using eval cheers for old code The shell is a sharp tool. If you're going to use it to try and cut your fingers off, it's not going to stop you. If you use it with care, you can usually accomplish what you need. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
cool, now that u're the main bash coder greycat and co wont fall like
cannibals over you for using eval
cheers for old code
On Mon, Jan 25, 2021, 17:18 Chet Ramey wrote:
> On 1/25/21 10:17 AM, Chet Ramey wrote:
> > I agree that it might be more useful if it
> > expanded to multiple words in contexts like
> >
> > copy=( "${assoc[@]@K}" )
>
> I forgot to mention that since the keys and values are both quoted so they
> can be reused, you can copy an associative array using a key-value
> assignment like
>
> declare -A copy
> eval copy=( "${assoc[@]@K}" )
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>
Re: Feature Request: scanf-like parsing
On 1/25/21 10:17 AM, Chet Ramey wrote:
I agree that it might be more useful if it
expanded to multiple words in contexts like
copy=( "${assoc[@]@K}" )
I forgot to mention that since the keys and values are both quoted so they
can be reused, you can copy an associative array using a key-value
assignment like
declare -A copy
eval copy=( "${assoc[@]@K}" )
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 1/22/21 11:54 AM, Oğuz wrote:
Since everyone's making feature requests here, it'd be a shame if I didn't
participate. I think it'd be better if `${assoc[@]@K}' expanded to a word
list instead of a single word.
It does, when it's subject to word splitting. In contexts where no word
splitting takes place, it expands to a single word, since it's supposed to
parallel the `A' transformation. I agree that it might be more useful if it
expanded to multiple words in contexts like
copy=( "${assoc[@]@K}" )
And, having ampersand as a reference for the
matched substring in the replacement part of `${param/pat/rep}` would also
be good.
There has been code to do this for a long time. It's currently tagged for
bash-5.2. If you want to play around with it, look in subst.c for
shouldexp_replacement and its caller, and uncomment them. You'll have to
wait for the next devel branch push for a version that works with multibyte
characters -- that should tell you how long it's been there.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 23/01/2021 05.16, Ángel wrote: > Why do you want to avoid the subshell? Do you want to modify some > variables there visible to the parent, or is it just for efficiency ? Both reasons are good in valid. My concern is more with the former, as variables within subshell cannot easily be accessed outside it. Peter
Re: Feature Request: scanf-like parsing
On 2021-01-23 at 00:47 +0700, pepa65 wrote: > It is otherwise very hard to get command output into a variable > without a subshell. > > Peter Why do you want to avoid the subshell? Do you want to modify some variables there visible to the parent, or is it just for efficiency ?
Re: Feature Request: scanf-like parsing
Le 22/01/2021 à 19:18, Léa Gris écrivait :
Now replace the the () with {}, replace the implicit temporary fifo by
and implicit temporary file; then have the same feature but without
spawning a sub-shell.
Instead of:
tempfile=$(mktemp) || exit 1
trap 'rm -f "$tempfile"' EXIT
compgen -u >"$tempfile"
mapfile -t users <"$tempfile"
You'd have:
mapfile -t users < <{ compgen -u;}
--
Léa Gris
Re: Feature Request: scanf-like parsing
On 23/01/2021 00.55, Greg Wooledge wrote: > People just have a deep, almost religious, loathing > against creating their own temp files. > > And yet, these same people are *perfectly* happy if some tool creates > a temp file for them -- as long as they don't have to see any of the > details or do any of the work. Yes, a temp file on a virtual filesystem in memory would work. I think the idea is to stay in RAM. But to then get it into a variable, you'd have to use mapfile, and then get the array to be in a single variable. There are quite a number of operations here that could be elided by some elegant syntactic sugar to the benefit of all. Peter
Re: Feature Request: scanf-like parsing
Le 22/01/2021 à 18:55, Greg Wooledge écrivait :
It's not hard at all. People just have a deep, almost religious, loathing
against creating their own temp files.
And yet, these same people are*perfectly* happy if some tool creates
a temp file for them -- as long as they don't have to see any of the
details or do any of the work.
Because handling a temp file properly is already a bit of additional
implementation that involves using trap for cleanup. Handling multiple
tempfiles with proper cleanup becomes a complex unreliable task if
implemented with Bash script commands.
So if a syntactic sugar does it all properly, safely and with proper
cleanup then it is good.
You could always implement the equivalent of:
read -r variable < <(command)
with creating a temporary fifo:
fifo=$(mktemp --dry-run)
trap 'rm -f "$fifo"' EXIT
mkfifo "$fifo" || exit 1
compgen -u >"$fifo" &
mapfile -t users <"$fifo"
But I really prefer this way because it is safer and much more reliable:
mapfile -t users < <(compgen -u)
Now replace the the () with {}, replace the implicit temporary fifo by
and implicit temporary file; then have the same feature but without
spawning a sub-shell.
--
Léa Gris
Re: Feature Request: scanf-like parsing
On Sat, Jan 23, 2021 at 12:47:58AM +0700, pepa65 wrote: > It is otherwise very hard to get command output into a variable without > a subshell. It's not hard at all. People just have a deep, almost religious, loathing against creating their own temp files. And yet, these same people are *perfectly* happy if some tool creates a temp file for them -- as long as they don't have to see any of the details or do any of the work.
Re: Feature Request: scanf-like parsing
On 22/01/2021 23.10, Léa Gris wrote:
> I'd prefer a syntax based off:
>
> command-list > >(command-list)
> command-list < <(command-list)
>
> But with curly braces for the no sub-shell version:
>
> command-list > >{ command-list;}
> command-list < <{ command-list;}
>
> Which could be used to assign output of a command to a variable without
> a sub-shell:
>
> mapfile -t users < <{ compgen -u; } # No sub-shell
That would be great. Of course mapfile maps lines to entries in an
array, but if I want them in a single variable, perhaps this could do:
{ ls;}>>>variable
Or even (if people prefer):
mapvar variable < <{ ls;}
It is otherwise very hard to get command output into a variable without
a subshell.
Peter
Re: Feature Request: scanf-like parsing
On 22/01/2021 22.36, Greg Wooledge wrote: > What are you talking about? <<< does not remove anything. It only adds > a newline, which can admittedly be irritating in some situations. Maybe the version <<<- can nor add a newline?? I was confused with trailing newlines being removed from $(pipeline). I can't think of a sensible syntax variant to mean to not remove those... Peter
Re: Feature Request: scanf-like parsing
On Fri, Jan 22, 2021 at 7:10 PM Léa Gris wrote:
> Which could be used to assign output of a command to a variable without
> a sub-shell:
>
It wouldn't be any different from
compgen -u > temp_file
mapfile -t users < temp_file
You can't run them asynchronously without forking.
Since everyone's making feature requests here, it'd be a shame if I didn't
participate. I think it'd be better if `${assoc[@]@K}' expanded to a word
list instead of a single word. And, having ampersand as a reference for the
matched substring in the replacement part of `${param/pat/rep}` would also
be good.
Re: Feature Request: scanf-like parsing
Le 22/01/2021 à 16:11, pepa65 écrivait :
I still love the idea of ">>>variable" to direct output into a
variable without needing a subshell
I'd prefer a syntax based off:
command-list > >(command-list)
command-list < <(command-list)
But with curly braces for the no sub-shell version:
command-list > >{ command-list;}
command-list < <{ command-list;}
Which could be used to assign output of a command to a variable without
a sub-shell:
Example:
mapfile -t users < <{ compgen -u; } # No sub-shell
Implementation-wise it could be a temporary file in /tmp or /dev/shm
rather-than a temporary named fifo as with < <(:).
--
Léa Gris
Re: Feature Request: scanf-like parsing
On Fri, Jan 22, 2021 at 09:57:15AM -0500, Daniel Colascione wrote: > On 1/22/21 9:54 AM, Saint Michael wrote: > > I vote for this new feature. > > Personally, I've found that scanf underpowered for parsing modern data > formats. Bash's existing regular expression support seems perfectly adequate > to me, and it can handle everything that scanf can. I'd only suggest > extending the regular expression syntax with support for named subgroups. Ah.. I forgot Bash now has regex. Just tried =~, and I can get the subgroups out. Request withdrawn. :-) -- William Park
Re: Feature Request: scanf-like parsing
On Fri, Jan 22, 2021 at 10:11:58PM +0700, pepa65 wrote: > I would like a "<<<" that doesn't cut off empty lines (perhaps "<<<-" ?) What are you talking about? <<< does not remove anything. It only adds a newline, which can admittedly be irritating in some situations. unicorn:~$ cat <<< $'one\n\nthree' one three The blank line in the middle is preserved.
Re: Feature Request: scanf-like parsing
On 1/22/21 10:11 AM, pepa65 wrote: I would like a "<<<" that doesn't cut off empty lines (perhaps "<<<-" ?) What does this mean? cat <<< $'one\ntwo\n\n\n' still outputs three trailing newlines. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 22/01/2021 21.57, Daniel Colascione wrote: > Personally, I've found that scanf underpowered for parsing modern data > formats. Bash's existing regular expression support seems perfectly > adequate to me, and it can handle everything that scanf can. I'd only > suggest extending the regular expression syntax with support for named > subgroups. The power and easy of use of the bash input handling is already superb compared with many other languages. I won't need this scanf extension. Anything that would make bash more robust and versatile has my preference of spending time on if voting is called for. I would like a "<<<" that doesn't cut off empty lines (perhaps "<<<-" ?) and I still love the idea of ">>>variable" to direct output into a variable without needing a subshell, so "2>>>errormsg" could be used to route stderr of a pipeline into the variable errormsg. Cheers, Peter
Re: Feature Request: scanf-like parsing
On 1/22/21 9:54 AM, Saint Michael wrote: I vote for this new feature. Personally, I've found that scanf underpowered for parsing modern data formats. Bash's existing regular expression support seems perfectly adequate to me, and it can handle everything that scanf can. I'd only suggest extending the regular expression syntax with support for named subgroups.
Re: Feature Request: scanf-like parsing
I vote for this new feature. On Fri, Jan 22, 2021 at 9:16 AM Chet Ramey wrote: > On 1/22/21 12:29 AM, William Park wrote: > > > But, if data are buried in a mess, then it's very labour-intensive to > > dig them out. It might be useful to have scanf()-like feature, where > > stdin or string are read and parsed according to the usual format > > string. I guess, it would actually be sscanf(), since 'read' builtin > > reads a line first. Since you're dealing with strings, only %s, %c, and > > %[] are sufficient. > > Sounds like a good candidate for a loadable builtin. Anyone want to take > a shot at it? > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ > >
Re: Feature Request: scanf-like parsing
On 1/22/21 12:29 AM, William Park wrote: But, if data are buried in a mess, then it's very labour-intensive to dig them out. It might be useful to have scanf()-like feature, where stdin or string are read and parsed according to the usual format string. I guess, it would actually be sscanf(), since 'read' builtin reads a line first. Since you're dealing with strings, only %s, %c, and %[] are sufficient. Sounds like a good candidate for a loadable builtin. Anyone want to take a shot at it? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature Request: scanf-like parsing
On 2021/01/21 21:29, William Park wrote: Since you're dealing with strings, only %s, %c, and %[] are sufficient. You can't read numbers in sscanf? _Might_ be nice to be able to read a float as well even though it would need to be access/stored as a string. Would compliment ability to write out a floating point value using %f from a string. Why would you do that? To use the floating point round of printf to get float-vals to round up. Eh, would prolly want to scan it in with 2 integers now that I think about it (before + after decimal).
