search

sjjf / advanced-shell-history-old

Save your command line history in an sqlite3 DB. The original author has resurrected the project on github at https://github.com/barabo/advanced-shell-history.
Apache License 2.0
2 stars 3 forks source link

Feature Request - a safe way to get 'builtin type' details #2

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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 carl.and...@gmail.com on 27 Sep 2011 at 3:46

GoogleCodeExporter commented 9 years ago 
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 comment by carl.and...@gmail.com on 30 Jul 2012 at 3:58