Add ability to save any output automatically in bash

[artemrizhov]

It would be useful to have all outputs saved automatically without prepending commands with ah t --

[9seconds]

With ZSH it is rather simple:

function execute_with_ah {
    BUFFER="ah t -yx -- $BUFFER"
    zle accept-line
}

zle -N execute_with_ah_widget execute_with_ah
bindkey '^J' execute_with_ah_widget
bindkey '^M' execute_with_ah_widget

But since Bash has no real preexec hook it would be tricky. Right now I test it but cannot give any estimation (bash is tricky beast)

[artemrizhov]

Maybe it makes sense to send a feature request to bash developers. ;-)

[9seconds]

After bit of tests I came to the solution (mostly zsh) which is HORRIBLE shell script which does a lot of stuff to make auto execution actually work. This script is unmaintainable and basically I am scary about idea to support it. The reason is that some commands must be avoided by ah: cd for example. But you can't just filter them because command like `ah t -x -- "cd ..; find .; cd -" is perfectly valid for ah usage.

So I've decided to go by white lists. I'll add 3 new subcommands: ad, al and ar which do the following:

• ad adds a command to the list of commands which should be executed with ah automatically
• al list those commands
• ar removes commands from the list

This is perfectly safe and covers mostly all real world cases. But user has to avoid those cd ..; do; do_another && and_another patterns. At least on the first step.

[artemrizhov]

This is a bit tricky. The program is probably created to make the life more easy, but not for adding new problems. What about sending a feature request to bash developers?

Also I'd say that plain config file is more easy way to manage the program behaviour. The command that many users know already is vim ~/.program_name. No sense to learn new commands like ah (ad|al|ar).

[9seconds]

No, this is not about bash, this is about shells. I meet this problem with Zsh and Fish (#9) (Fish is even worse, I gonna reject to support it, no way to inject ah into his loop)

Those problems are exist because ah is not a part of any shell. It is hard to interfere into the shell to understand aliases, one-liners like cd ..; do && do_another; cd -- (where to put ah here?). And some problems makes no sense to ah: vim, let's say. Some programs require to be executed with pseudoTTY (vim for example), some - with interactive mode (-x. for example, I use long aptg function). We need to have some way to manage that zoo.

My proposal is to have some kind of whitelisting of commands: by default, ah will ignore execution but if command was added, it will work.

Actually, it is already on master. Let's check my whitelist:

➜ ah al
ag                   [interactive=false, pseudoTty=false]
find                 [interactive=false, pseudoTty=false]
grep                 [interactive=false, pseudoTty=false]
ll                   [interactive=true , pseudoTty=false]
ls                   [interactive=false, pseudoTty=false]
python               [interactive=false, pseudoTty=false]
ssh                  [interactive=false, pseudoTty=false]

ll is alias, so it is executed in shell. So anytime I type

➜ python some_script.py

it is converted to

➜ ah t -- python some_script.py

And ll goes to ah t -x -- "ll". Works as charm, already in master.

I agree with you on configs, but basically it is too long to add new command to the list with proper options. You type vim ~/.ah/auto_commands and with a dozen of keystrokes add new command. I add it with just ah ad command (or ah ad -x command for interactive mode). I understand what do you mean, but basically it is just faster. By keystrokes at least.

[artemrizhov]

Ok, I see. Thanks for the explanation.

This still seems too complicated. I'd have to add each command to the white list.

Maybe it makes sense to add some tiny layer between the terminal (emulator) and the shell?

[9seconds]

Will you please elaborate?

[artemrizhov]

Well, I'm not sure how to implement this, but the idea is to create a tiny terminal emulator that should be run inside of another terminal. Something like screen, but much more simple. It should just redirect stdin and stdout between the parent terminal and the shell, and log anything with timestamps. Later the timestamps can be used to find a beginning of command output.