For my developer work I reside in the *nix shell environment pretty much all day, but still can't seem to memorize the name and argument specifics of programs I don't use daily. I wonder how other 'casual amnesiacs' handle this. Do you maintain an big cheat sheet? Do you rehearse the emacs shortcuts when you take your weekly shower? Or is your desk covered under sticky notes?
Using bash_completion is one way of not having to remember the precise syntax of program arguments.
> svn [tab][tab]
--help checkout delete lock pdel propget revert
--version ci diff log pedit proplist rm
-h cleanup export ls pget propset status
add co help merge plist pset switch
annotate commit import mkdir praise remove unlock
blame copy info move propdel rename update
cat cp list mv propedit resolved
If I don't use a command regularly enough to remember what I want, I tend to just use --help or the man pages when I need to.
Or, if I'm lucky, I use CTRL+R and let bash's history search find when I last used it.
Eventually you just remember them, well the set that you use anyway. I used to maintain a README in my home directory when I was starting out but that disappeared many years ago.
One useful command is man -k which you pass a word to and it will return a list of all commands whose man page summary contains that word.
'apropos' is also a very useful command. It will list all commands whose man pages contain the keyword.
Related
I'm using oh-my-zsh which pipes the output of some functions like git diff and git log into less, whilst this is great for reading the output in the terminal. If I need to refer back to it it isn't possible after quitting with :q
Is there an option to preserve the current view on the file in my terminal after quitting?
Secondly, If there is an option where would I need to edit my oh-my-zsh config to ensure anything piped to less passes this option?
To prevent less from clearing the screen on exit you can start it with the option -X:
less -X FILE
If you want to pass this option automatically to every instance of less, you can set the LESS environment variable accordingly in your ~/.zshrc:
export LESS="-X"
Note:
If your shell has syntax coloring enabled, the -X option will cause your less output to display those color change escape sequences as inline ESC text.
This can be fixed by also passing the raw-control-chars display option, -r. For example:
export LESS="-Xr"
This also includes instances where less is started by another program, for example man. If you want to disable this option for a single command, you can just prepend LESS=. For example
LESS= man less
For Git specifically, this can be handled with the following
git config --global color.ui true
git config --global core.pager 'less -Xr'
Is there a way to make zsh complete parameters of commands (just like the fish shell do). For example, when I type ls -- and use TAB it will pop up a list of all ls parameters.
I know that I can use fish shell for this, and I know that fish shell is amazing, but there is a lot of missing functionalities in the fish shell. That's why I am looking to bring this parameter completion in zsh.
Try with single hyphen, like ls -. All built in commands are working fine. Btw for custom oh-my-zsh plugin autocompletion, it depends on plugin configuration.
oh-my-zsh has over 200 plugins for different commands. But unfortunately the auto completions are all hand made. So there will be never auto complete function for every command.
I have a query regarding the execution of a complex command in the makefile of the current system.
I am currently using shell command in the makefile to execute the command. However my command fails as it is a combination of a many commands and execution collects a huge amount of data. The makefile content is something like this:
variable=$(shell ls -lart | grep name | cut -d/ -f2- )
However the make execution fails with execvp failure, since the file listing is huge and I need to parse all of them.
Please suggest me any ways to overcome this issue. Basically I would like to execute a complex command and assign that output to a makefile variable which I want to use later in the program.
(This may take a few iterations.)
This looks like a limitation of the architecture, not a Make limitation. There are several ways to address it, but you must show us how you use variable, otherwise even if you succeed in constructing it, you might not be able to use it as you intend. Please show us the exact operations you intend to perform on variable.
For now I suggest you do a couple of experiments and tell us the results. First, try the assignment with a short list of files (e.g. three) to verify that the assignment does what you intend. Second, in the directory with many files, try:
variable=$(shell ls -lart | grep name)
to see whether the problem is in grep or cut.
Rather than store the list of files in a variable you can easily use shell functionality to get the same result. It's a bit odd that you're flattening a recursive ls to only get the leaves, and then running mkdir -p which is really only useful if the parent directory doesn't exist, but if you know which depths you want to (for example the current directory and all subdirectories one level down) you can do something like this:
directories:
for path in ./*name* ./*/*name*; do \
mkdir "/some/path/$(basename "$path")" || exit 1; \
done
or even
find . -name '*name*' -exec mkdir "/some/path/$(basename {})" \;
Since I'm stuck with Subversion and shell tools for the time, git-gui and such are out of the question. Are there any shell tools to apply a patch line-by-line interactively?
Try passing the --dry-run option to patch. This will let you identify the problem hunks and edit the patch and/or file being patched appropriately.
ipatch brings the power and convenience of selecting and editing patches in Darcs to those who are not using the Darcs version control system.
It allows the user to interactively split a patch file into several patch file, as well as applying a patch interactively and possibly partially.
There's an introduction from the author here.
See this answer.
Although not interactive, another option is to manually edit the .diff file and remove any changes you don't want.
If you open a diff file in emacs and put the editor in diff-mode you can edit patches and emacs will try to update the hunk markers. (Emacs will open .diff files in diff-mode automatically.)
To update markers manually after making changes do C-c C-w to regenerate the hunk.
To apply hunks one by one do C-c C-a. To reverse-apply do C-u C-c C-a. You can also M-x diff-tell-file-name to apply them to a different file.
I found patch original patch.diff to be more reliable than patch < patch.diff and patch files created with diff -u to be easier to work with.
Information also documented here.
UPDATE [5.21.21]:
C-c C-s lets you split up hunks which is very useful for manually editing. Sometimes C-c C-w (diff-ignore-whitespace-hunk) does not do what you intended, so the safest bet is to split the hunks and let emacs update the headers automatically. This is especially useful when keeping lines unchanged; just split into a hunk and delete to remove the change.
How to create a new environment variable in unix and use it in a program??????
You can tell what shell you're running by ps -o comm= -p $$ — I think that's more-or-less universal. So, in bash and certain similar shells...
If you want to create the variable for one specific run, you can do
MYVAR=value the_command_that_needs_myvar
If you want to create it for an entire shell session (ie. until you log out):
export MYVAR=value
...and then you can run:
the_command_that_needs_myvar
...as many times as you like during that session, and it will still see MYVAR as having the value value.
If you want it to be set for yourself, for all your login sessions, put it in ~/.profile.
Please note that bash's initialisation files can be one great big WTF. Depending on whether it is run interactively, over a network, locally, AND depending on whether it is invoked as sh or bash, it will selectively read some combination of ~/.bashrc, ~/.profile and ~/.bash_profile. Read the FILES section of the bash man page for details.
If you want it to be set for every user, every time they log in, put it in the file /etc/profile (although there's also /etc/environment, I'm not sure how widely used that is.).
Check out the question "How to set environment variable for everyone under my linux system?" for some more details, too.
(Beware, some of this advice will vary depending on if you, or other users, use bash, dash, csh, ksh, etc... but it should work for most use cases.)
Depends on the shell. In bash, you can use:
export myvar=xyz
which will set the variable and make it available to other programs.
If you want to set it for one invocation of a program, you can use:
myvar=xyz ./myprog
This will have it set for the myprog process but not after it exits.
See setenv(3) and getenv(3) functions.