Re: is there a way to save stdout and stderr to two bash variables?

[Pier Paolo Grassi]

Yu, is there a stringent argument for you to use bash for your tasks, when
I think it's been cleared that bash is not the best tool for code that need
to be as performant as possibile?
Put in another way, isn't it costly to try to do in bash things that could
and maybe should be done directly with c, or another most suitable language
(maybe go, or rust?)
Very curious about your motivations here


Il giorno mar 12 mag 2020 alle ore 12:24 Peng Yu <address@hidden> ha
scritto:

> On Tue, May 12, 2020 at 5:19 AM Andreas Kusalananda Kähäri <
> address@hidden> wrote:
>
> > On Tue, May 12, 2020 at 04:44:09AM -0500, Peng Yu wrote:
> > > On Mon, May 11, 2020 at 7:45 PM Koichi Murase <address@hidden>
> > > wrote:
> > >
> > > > 2020-05-12 6:13 Peng Yu <address@hidden>:
> > > > >
> > > > > But this solution still involves using external files if I read the
> > > > > code correctly? Thanks.
> > > >
> > > > Yes, as already explained in the original post of `ble/util/assign'.
> > > > If you don't want to use external files, you can instead use nested
> > > > command substitutions and variable exports by `declare -p':
> > > >
> > > >   function cmd {
> > > >     echo this is stderr >&2
> > > >     echo this is stdout
> > > >   }
> > > >
> > > >   eval -- "$(
> > > >     { stderr=$(
> > > >         { stdout=$(cmd); } 2>&1
> > > >         declare -p stdout >&3); } 3>&1
> > > >     declare -p stderr )"
> > > >
> > > >   echo "($stdout)($stderr)"
> > > >
> > > > If you feel it is cumbersome to write it every time, again you can
> > > > wrap it in a function:
> > > >
> > > >   function upvars {
> > > >     while (($#)); do
> > > >       unset "$1"
> > > >       printf -v "$1" %s "$2"
> > > >       shift 2
> > > >     done
> > > >   }
> > > >   function save-stdout-stdin {
> > > >     eval -- "$(
> > > >       { printf -v "$2" %s "$(
> > > >         { printf -v "$1" %s "$(eval -- "$3")"; } 2>&1
> > > >         declare -p "$1" >&3)"; } 3>&1
> > > >       declare -p "$2" )"
> > > >     upvars "$1" "${!1}" "$2" "${!2}"
> > > >   }
> > > >
> > > >   save-stdout-stdin a b cmd
> > > >   echo "($a)($b)"
> > > >
> > > > However, these solutions require at least three forks which are
> slower
> > > > than the external file accesses.  There is no solution with neither
> > > > forks nor external file accesses.  In my opinion, there is no reason
> > > > to refrain from external files as far as the files are created in
> > > > memory (tmpfs such as /dev/shm or /tmp) and the permissions are
> > > > properly mainined.
> > > >
> > > > Also, if you do not allow even internal usages of external files at
> > > > all, you cannot use here documents and here strings as they also use
> > > > temporary files internally.  For example, you can confirm this by the
> > > > following command.
> > > >
> > > > $ ls -la /dev/fd/0 <<< Here
> > > > lr-x------. 1 murase murase 64 2020-05-12 09:42:22 /dev/fd/0 ->
> > > > /tmp/sh-thd.ZLmXgN (deleted)
> > >
> > >
> > > I didn’t know that this was the case. I always thought heredoc was in
> > > memory.
> > >
> > > Chet, There was not an in memory implementation of here doc possible in
> > > bash? How much performance difference it could be comparing in memory
> and
> > > temp file (suppose temp file is not in a RAM disk)?
> >
> > Theoretically, I don't think you can assume that a here-document can be
> > stored in RAM as its size is only limited by the storage medium that
> > hold the script that it is part of.
>
>
> I am not sure this statement is relevant to most real usage. I mostly use
> heredoc for short strings, it would be costly to use external files instead
> of in memory strings.
>
> >
> >
> > --
> > Andreas (Kusalananda) Kähäri
> > SciLifeLab, NBIS, ICM
> > Uppsala University, Sweden
> >
> > .
> >
> --
> Regards,
> Peng
>