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 o
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 >"$tem
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 of
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 *perfect
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 as
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 $(pipeli
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 eve
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
I am ashamed to say, /dev/null being a regular file was the source of
the problem.
Actually this was one of the very first ideas I had and I tested against
it in multiple ways. I ran:
echo asdf > /dev/null ; cat /dev/null and cat /dev/null
several times, always returning empty. It must h
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 <<< $'one\n\
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, vit
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 expres
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 exten
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
i had similiar where i used exec socat for file transfer daemon and client,
and sometimes codes of the code or cmds appeared in output, till i removed
the exec
On Fri, Jan 22, 2021, 15:15 Chet Ramey wrote:
> On 1/22/21 2:53 AM, Eduardo A. Bustamante López wrote:
>
> > - Notice that the value ret
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 1/22/21 2:53 AM, Eduardo A. Bustamante López wrote:
- Notice that the value returned by `fstat(0, ...)' indicates that /dev/null in
your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but
instead it is `st_mode=S_IFCHR|0666'). It also indicates that its size is 73
bytes (
On 1/22/21 12:31 AM, L A Walsh wrote:
Isn't it possible
to load from one place (which would get copied to the 2nd as older history)
and then bash move around to delete dups as needed in the new file?
That's what happens now, execept there's no moving around in a file.
--
``The lyf so short, th
Still strange that downgrading helps shouldnt
touch
/dev/null .
22 Ocak 2021 Cuma tarihinde Eduardo A. Bustamante López
yazdı:
>
> - Notice that the value returned by `fstat(0, ...)' indicates that
> /dev/null in your system is a *regular* file (it should be
> `st_mode=S_IFCHR|0666', but instead it is `st_mode=S_IFCHR|0666'). It also
> indicates that its size
On Fri, Jan 22, 2021 at 8:53 AM Eduardo A. Bustamante López
wrote:
> These are worth highlighting:
>
> - Notice that the value returned by `fstat(0, ...)' indicates that /dev/null
> in your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but
> instead it is `st_mode=S_IFCHR|0666
24 matches
Mail list logo
