You can pass variables into the environment with the export command.
For example, you can export foo. This causes all child processes of the shell where you run export to know about that variable. You can change the value later and the change will also be passed to child processes (so you only need to export a variable once).
liah Kagan gave me a nice example for this. The handy GNU date command will look for the TZ variable, and use it if it is set, which it probably is not on your system yet. Try running it
date
zanna@peach:~/playroom$ date
Sunday 11 October 2020 09:34:15 PM IST
That's very kind, but I only contributed the idea to demonstrate environment variables by running date with TZ set, not the specific progression of commands and explanation -- which is actually better than the way I have shown people, and I shall be linking to it here, I think, to help people in the future.
@user3140225 yes :) that demonstrates that you don't have to export again after changing the value - the date command got the update. This is always the case when you change an environment variable - you don't have to export a variable that is already in the environment, you can just assign a new value to it (although nothing bad happens when you unnecessarily export a variable that is already exported).
@technastic_tc sure, but I guess that's what you had at the start?
You can also run export variable=value, combining the two steps of assigning a value to a variable and passing it into the environment into one step. So instead of doing TZ=UTC and then later export TZ, We could have just run export TZ=UTC
Note that if you open a new terminal, the shell that opens won't be a child of the shell you exported from, so it will not know about that variable. To set an environment variable that all shells will know about, you could export it in .profile.
There is a command that lists only environment variables - it is printenv
@EliahKagan that comes a bit later due to jumping around a bit trying to create some files to play with... I'll have to think about how best to resume though so it can get rearranged
Thank you so much for participating @αғsнιη @karel @user3140225 @EliahKagan @jokerdino @technastic_tc @terdon and anyone else who was here - you have been awesome!
@jokerdino There's also an external command called time. If you want to time with the time builtin how long the external time command takes to run date to time how long date takes then you could run time command time date (or time \time date).
@jokerdino Sorry, I made a mistake in saying "the time builtin." time in bash is actually a shell keyword (per type time) rather than a shell builtin, which is necessary so that it can be used to time any pipeline.
On a more serious note, I'm afraid I'm working full tilt these days dealing with a crisis at work, so I couldn't participate as I'd have liked to. But here's one nifty tip that makes my life on the command line much easier:
Open the file $HOME/.inputrc in your favorite editor (e.g. nano ~/.inputrc) and add these two lines:
Now, save and close the file and open a new terminal. You know how hitting the Up button cycles through the command history? Now, with these lines, if you start typing and then press the Up, only commands that started with what you've typed will be shown. This makes it very easy to find the specific commands you were after.
I rarely edit .inputrc and I don't know its syntax. On some systems I don't have that file in my home directory. When I create it, do I need to source/include/whatever another file to retain all the other behavior?
I seem to recall something about this but I don't know if that's true.
Like, does it still also use /etc/inputrc if ~/.inputrc is present?
@EliahKagan Yes. Or, at least, I believe so. I know that I've been using the same ~/.inputrc for years and I've never had any issues. It also makes sense that it would work like other rc files: your ~/.foorc will be read last, so anything in there will overwrite stuff from the system files, but if you haven't explicitly changed a setting, the original one from the system file will be in effect.
The other ones I use a lot are Alt+Left and Alt+forward to move one word backwords or forwards respectively
"\e[1;3D": backward-word ### Alt left
"\e[1;3C": forward-word ### Alt right
I find those easier to use than the default Alt+b and Alt+f
/etc/inputrc on my system (probably on all Ubuntu systems?) has:
# mappings for Ctrl-left-arrow and Ctrl-right-arrow for word moving
"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word
So I think I'll source/include /etc/inputrc in my new custom ~/.inputrc to keep that and other default goodies while also having that nice functionality. (Since I've just tested and found that I lose that behavior when I have my own ~/.inputrc.) Now I just have to look up now to do that...
@terdon When I don't have a ~/.inputrc file, Ctrl+Left and Ctrl+Right move left and right one word. When I do have it, they print ;5D and ;5C instead. I presume the other stuff in /etc/inputrc is likewise not run when I have an .inputrc in $HOME. But I recall there is some way to source /etc/inputrc in ~/.inputrc. I'd rather do that than copy its contents.
Unfortunately, code fences don't work in chat. You can indent four spaces though. If you have more than one line in a message, the UI adds a "fixed font" button (to the right of the "upload..." button) to automatically indent every line of the message by four spaces.
$include /etc/inputrc
set completion-ignore-case On
set colored-completion-prefix On
set colored-stats On
set show-all-if-ambiguous On
set show-all-if-unmodified On
set mark-symlinked-directories On
set menu-complete-display-prefix On
"\t": menu-complete
"\e[Z": menu-complete-backward
"\e[A": history-search-backward
"\e[B": history-search-forward
According to man readline:
$include
This directive takes a single filename as an argument and reads commands and bindings from that file. For example, the following directive would read /etc/inputrc:
$include /etc/inputrc
Speaking of ignoring case, I noticed something during the lesson that I either never knew or had forgotten: man runs less with the -i option (by putting it in $LESS), so searching with / and ? is case-insensitive. Something else that I probably should've known but didn't is, you can specify options interactively, while less is running, by typing something that starts with a -. So I can make less have case-insensitive searching while it's already running by typing -i in it.
@EliahKagan The Linux bit is probably Linux, yes. I was (mis)using the word "Linux" to mean "GNU/Linux Operating System", meaning all the various bits and bobs and file locations and home dirs etc. Those I would expect to change since they have nothing to do with the kernel.
A WSL system has its own filesystem, with mount points to access stuff in the Windows system outside of it. So within the WSL system, most userland stuff is in the expected places.
Though it's set up in such a way that PATH lookup also finds Windows programs (which can be run from inside the WSL system... sometimes with the desired effect), and that's fairly weird.
The one (intentional) use I've found for that is to redirect or pipe to clip.exe.
According to man readline:
$include
This directive takes a single filename as an argument and reads commands and bindings from that file. For example, the following directive would read /etc/inputrc:
$include /etc/inputrc
