You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem:
I want to know which actual binary a command used. However, sometimes the
'command' was actually a shell alias or a shell function. The best way to know
is to look at the output of the shell builtin 'type'.
The problem with this, is that it's unsafe to evaluate the previous command
within the shell code using type, because it potentially re-executes the
command.
For example:
I entered the command:
$ less ` which installer.py `
I am interested in 'less' and I'm interested in 'which' - I want to know which
binaries I was actually using. The actual previous command, as saved in the
history db is: 'less ` which installer.py `'
The naive approach is to simply invoke 'eval type "${previous_command}"', which
will evaluate to: eval type "less /some/path/to/installer.py"
This gives me information for 'less', but it fails to give me information for
'which' - instead I get information for /some/path/to/installer.py.
What is likely needed is a simple binary helper that takes a raw command as
input and parses it to identify the command parts of it ('less' and 'which')
and strip out the other parts.
For example:
$ ash_helper -c 'less ` which installer.py `'
less which
$ builtin type $( !! )
less is /usr/bin/less
which is /usr/bin/which
Having this utility makes it possible to effectively filter garbage commands.
For example, if I accidentally entered 'sl' instead of 'ls' - I might not care
to see that in my history. However, if I entered 'ls foo' and foo does not
exist, I'll get an error code for the command. I probably want to see this in
my history. Since both cases have an error exit code, I can't filter by exit
code alone. I need to know if the invoked binary exists or not to filter
garbage commands.
Original issue reported on code.google.com by [email protected] on 27 Sep 2011 at 3:46
The text was updated successfully, but these errors were encountered:
I should clarify that one of the main goals of this feature is to have a way to
filter commands where a user enters a password on the command line
accidentally. The assumption is that the password is not a real command, so by
filtering out non-commands (including typos) passwords will avoid being
displayed.
It would also be possible to request that they not be stored in the database or
logged to file in the first place.
Original issue reported on code.google.com by
[email protected]
on 27 Sep 2011 at 3:46The text was updated successfully, but these errors were encountered: