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
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
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
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.
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
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.
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
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
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
-- Forwarded message -
From: Alex fxmbsw7 Ratchev
Date: Mon, Jan 25, 2021, 19:14
Subject: Re: Feature Request: scanf-like parsing
To: Eli Schwartz
On Mon, Jan 25, 2021, 18:58 Eli Schwartz wrote:
> On 1/25/21 12:48 PM, Alex fxmbsw7 Ratchev wrote:
> > you havent been
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.
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
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
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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
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 ?
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
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
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
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
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
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
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
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:
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
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 <<<
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,
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
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
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
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(),
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
Another feature request:
To parse out simple thing like IP components, you can do something like
IFS=. read a b c d <<< "11.22.33.44"
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
46 matches
Mail list logo
