Re[9]: Subshell exit trap is not invoked if shell exit trap also set
Al, thank you for your time. Being under the impression of your experiment, I went back to my setup, looked at it thoughtfully for a while, and realized that bash-5.* ... if fact works. There was a unfortunate mistake of mine: I launched [ssxtrap] from inside interactive bash-5, but ... as [./ssxtrap], literally. My fault, sorry for noise. It looks like Dmitry was right, and this bug is fixed since bash-4.4. Thank all for help. Regards, Konstantin. Al Payne, 26 Mar 2019 22:55 MSK: I also tried to replicate on CentOS (under Fusion), but get the two expected trap messages when killing the internal process: ext pid=25449 int pid=25450 int exit trap in 25450 subshell done ext exit trap in 25449 Test install: - CentOS Linux release 7.2.1511 (Core) [under VMware Fusion] - kernel-3.10.0-327.el7.x86_64; glibc 2.17 - GNU bash, version 5.0.3(1)-release Dmitry Goncharov, 26 Mar 2019 18:58 MSK: Double check that this reproduces with bash-5. I was able to reproduce this with bash-4.2 and earlier. This does not reproduce for me with bash-4.4 and later. Konstantin Andreev, 25 Mar 2019 22:48 MSK: Verified on: Solaris 11.3, bash 4.1.17(1)-release (i386-pc-solaris2.11) CentOS Linux 7.2.1511, bash 4.2.46(1)-release (x86_64-redhat-linux-gnu) CentOS Linux 7.2.1511, bash 5.0.0(1)-release (x86_64-pc-linux-gnu)
Feature request or advice on implementation for buffering command output
Usecase:
You run a command, the output is displayed in your terminal. Now that you
see the output, you would like to grab say an ID from this output. Instead
of coping and pasting the output, I would like to be able to do something
like:
# grep 'the thing that you want' <<< ${COMMAND_OUTPUT} | ./some_script
Where COMMAND_OUTPUT is the last n number of output lines from the previous
command.
Now, I've looked at several ways of implementing this is Bash. They all
break in various ways, because it usually means pushing all output to a
file/variable and then pushing it to stdout. Would it be feasible to have
Bash tee off anything intended for stdout to a variable?
Is there already some way of achieving this functionality?
If not, could anyone give me some pointers as to where or how this could be
implemented?
Thanks
Anders Brujordet
Re: Feature request or advice on implementation for buffering command output
On Wed, Mar 27, 2019 at 12:49:45AM -0700, Anders Brujordet wrote:
> Usecase:
> You run a command, the output is displayed in your terminal. Now that you
> see the output, you would like to grab say an ID from this output. Instead
> of coping and pasting the output, I would like to be able to do something
> like:
> # grep 'the thing that you want' <<< ${COMMAND_OUTPUT} | ./some_script
>
> Where COMMAND_OUTPUT is the last n number of output lines from the previous
> command.
>
> Now, I've looked at several ways of implementing this is Bash. They all
> break in various ways, because it usually means pushing all output to a
> file/variable and then pushing it to stdout. Would it be feasible to have
> Bash tee off anything intended for stdout to a variable?
No. When bash runs commands, bash does not "see" the output of those
commands unless you specifically go out of your way to make it do so.
The output of a command goes directly to a terminal (or a file, but let's
assume a terminal for the purposes of this argument). It does not go
"through" bash on the way to the terminal. Bash does not know whether
any output was written to the terminal at all, let alone how much output
was written, let alone what it was.
> Is there already some way of achieving this functionality?
No.
> If not, could anyone give me some pointers as to where or how this could be
> implemented?
You would have to ask your terminal for the most recent output it has
received (or the output on the bottom 3 lines, or whatever). How to do
this would be specific to your terminal. If you're using screen or tmux,
then it might actually be possible, but I wouldn't know *how*. You'd
need to ask a screen or tmux mailing list for help with that, if you can't
find it in the manuals.
If you are not using screen or tmux, then you might as well be chasing
an impossible dream. It's *probably* impossible, or so impractical that
you will not do it unless you're insane. In any case, the possibility
or feasibility of extracting already-written data from a terminal is
going to depend on the terminal. Every terminal is special, as in
special needs. No two are alike.
Using Source within Binary Shell Scripts
I was provided a shell script that is self decrypting, self unzipping, and checks if the file has been tampered with using an encrypted MD5 sum. The file uses the filename, command line parameters and some trial data to create the encryption key in a shell variable which it uses to decrypt an embedded encrypted zip file and execute the actual code (which immediately deletes the unencrypted file after it executes). I managed to decrypt the file because the code write a hidden file to /tmp before it deletes the unencrypted file and running chattr +a /tmp keeps the file from being deleted after it executes. The problem I'm having is that I can't run the command source filename.sh because the file is "binary". I cloned the source code from git and modified three .c source files to let me execute source filename.sh. This allowed me to actually view the password (because they don't clear the variables after execution) by typing in echo $PASSWORD_VARIABLE. The point is, their is a legitimate use for sourcing Binary Shell Scripts and BASH as is, won't let you do this. Maybe not allow it by default but have a parameter to ignore the file check to see if it is binary. Jason Hall
Re: Using Source within Binary Shell Scripts
On Wed, Mar 27, 2019 at 8:17 AM Jason Hall wrote: (...) > The point is, their is a legitimate use for sourcing Binary Shell > Scripts (...) Is it really a legitimate use? If you're doing it for "security" (by obscurity I guess?), it's easy to defeat. > and BASH as is, won't let you do this. Maybe not allow it by > default but have a parameter to ignore the file check to see if it is > binary. How would that work though?
Re: Feature request or advice on implementation for buffering command output
On 3/27/19 3:49 AM, Anders Brujordet wrote:
> Usecase:
> You run a command, the output is displayed in your terminal. Now that you
> see the output, you would like to grab say an ID from this output. Instead
> of coping and pasting the output, I would like to be able to do something
> like:
> # grep 'the thing that you want' <<< ${COMMAND_OUTPUT} | ./some_script
>
> Where COMMAND_OUTPUT is the last n number of output lines from the previous
> command.
>
> Now, I've looked at several ways of implementing this is Bash. They all
> break in various ways, because it usually means pushing all output to a
> file/variable and then pushing it to stdout. Would it be feasible to have
> Bash tee off anything intended for stdout to a variable?
In general, no. Keep in mind that the majority of output is performed by
external commands executed in subshells anyway.
--
``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: Using Source within Binary Shell Scripts
On Wed, Mar 27, 2019 at 09:09:37AM -0700, Eduardo Bustamante wrote: > On Wed, Mar 27, 2019 at 8:17 AM Jason Hall wrote: > (...) > > The point is, their is a legitimate use for sourcing Binary Shell > > Scripts (...) > > Is it really a legitimate use? If you're doing it for "security" (by > obscurity I guess?), it's easy to defeat. The original message reads like Jason is attempting to defeat the 'security' on a self-decrypting script by using source to add the script's variables to the current shell so their values can be viewed. Better ways to do this is a question for the help list. It's not a bug. Al
Re: Using Source within Binary Shell Scripts
On 3/27/19 2:22 PM, Al Payne wrote: > On Wed, Mar 27, 2019 at 09:09:37AM -0700, Eduardo Bustamante wrote: >> On Wed, Mar 27, 2019 at 8:17 AM Jason Hall wrote: >> (...) >>> The point is, their is a legitimate use for sourcing Binary Shell >>> Scripts (...) >> >> Is it really a legitimate use? If you're doing it for "security" (by >> obscurity I guess?), it's easy to defeat. > > The original message reads like Jason is attempting to defeat the 'security' > on a self-decrypting script by using source to add the script's variables to > the current shell so their values can be viewed. > > Better ways to do this is a question for the help list. It's not a bug.\ There was a feature request in there. It's just not high priority. -- ``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/
