Showing posts with label bash. Show all posts
Showing posts with label bash. Show all posts

Monday, July 23, 2012

bash fc - fix command cheatsheet

bash's BUILTIN fc command (fix command) is very useful and generally under-utilised. Here is a quick cheatsheet of some common fc commands which can be very useful indeed.

Personally it was hard to recall and decrypt the man bash fc section, so I wrote up a little cheatsheet for future reference, as follows.
$ fc -l 5680 5690
This will echo the commands in the shell history from 5680 5690. No execution.
$ fc -l -5 (minus the letter L and minus the number one)
This will echo the last 5 commands in the shell history, the same as history 5. No execution.

CAREFUL! The following commands require care, so that you don't inadvertently execute commands on your system! Please read how they work and how to handle them before trying them for yourself!
$ fc 5699 (careful!)
This opens the editor stored in FCEDIT, falling back on EDITOR. If neither env var is set, vi is used.
The editor will be populated with history line 5699 in this example.
When editing is complete, the commands are echoed and executed!
If you don't want to execute anything, ensure the file is empty and save and exit.
$ fc 5680 5690 (careful!)
Same as above but the editor will contain the commands within the shell history range.
If you don't want to execute anything, ensure the file is empty and save and exit.
$ fc -10 -1 (careful!)
Same as above but the editor will contain the last 10 commands in the shell history.
If you don't want to execute anything, ensure the file is empty and save and exit.
$ fc -s number|command (careful!)
Where number matches a shell history number OR command will match the the most recent shell history command that begins with command, then execute the command.
$ fc -s match=replacement number|command (careful!)
Same as above and each instance of match is replaced by replacement, then execute the command.

Feel free to checkout man bash to learn more in depth about this command including some options I didn't cover here.

Friday, March 23, 2012

testing for interactivity in a bash script

problem: you want to know if your bash script is being run interactively or not

This can be very useful to know, for example, if you want to programmatically determine if you should output to stdout, OR only to a log file because your script is running non-interactively.

When a script is running interactively, it means a stdout is present and one can output things to stdout and the user will see them.

When a script is running non-interactively, for example when cron runs a script, stdout does not exist.

solution: check if stdout is a tty

As with so many things, there is more than one solution, but this one seems to be rock solid and very portable.
is_interactive() { if [ -t 1 ]; then return 0; else return 1; fi }
As The Advanced Bash-Scripting Guide points out, for a complete test, one needs to check if stdout could be a socket too. Here is is the improved check:
is_interactive() { if [[ -t 1 || -p /dev/stdout ]]; then return 0; else return 1; fi }
I hope you enjoy and have fun tuning to your needs.
FYI. I tested the functions with cron and ssh on Debian squeeze (6.0.4) and bash 4.1.5.

citation:

Props to:
The Advanced Bash-Scripting Guide

How do I ask screen to behave like a standard shell?

I have found myself asking this question a few times, but never really got motivated to find a solid answer until recently.

I stole the question title from a good thread over at serverfault. Where I also contributed my findings.

I hope this share helps someone!

citation:

Props to:
rg3 @ LinuxQuestions.org for this share.