Sometimes I'd like to know what my shells aliases/functions are before I execute them. Can I log them without executing them? - shell

I'm not sure if this is a stupid question but I'll often run into the sinario were I don't know what my commands are set to are without having to open my .zshrc (I'm using zsh obviously).
For instance lets use gs. I'm not sure which of the following gs will execute:
alias gs="git status"
or alias gs="gulp serve"
or alias gs="grunt serve"
Is there a command, or something like echo gs, "$(gs)" or echo "$(gs)" that will log the command (e.g. git status) rather executing what ever I have gs set to?

You can run the alias command to print out all of your shell aliases. If you want to know what a particular alias resolves to, just pass it to the alias command as an argument:
➜ alias gs
gs='git status'

Related

aliases are not stored in zsh history

Whenever I execute a command using an alias, this command is not stored in the shell's command history.
So if I run history these commands do not appear in the list.
Nor do they appear when I press CTRL + r for reverse searching the command history.
When I press the keyboard's arrow up for scrolling through the last commands, I will see an aliased command only if it was the last command I ran. Other aliased commands are will not be displayed.
For example:
$ cd my-repo
$ gs # an alias to git status
$ history
Outputs the following:
2374 cd my-repo
(the gs command is not displayed)
A few notes:
gs is only an example. The issue is far more annoying in more complex commands since I have to retype them all over again instead of executing them from history (e.g. k get pods | grep <pod_name>, where k=kubectl).
gs is defined so: alias gs=' git status'.
I also have a few functions in ~/.alias, e.g.:
mkcd () {
mkdir -pv $1
For some reason, mkcd (or any other function in the alias file) is included in the history.
I do not mind if it prints out gs or expands to git status, I'll take any of the two...
I am using zsh with oh-my-zsh on macOS (Monterey). My shell aliases are defined in ~/.alias which is sourced in ~/.zshrc (source ~/.alias).
This happens both in iTerm2 and in the default Mac terminal.
Thank you for taking the time to help :-)
I will assume that your example alias is exactly what you have in your ~/.alias file.
So you have aliases like this (notice the space character in front of git command):
alias gs=' git status'
There is an shell option called HIST_IGNORE_SPACE which is doing exactly what you are experiencing - in short it will not add command to the history when it starts with space character. Example:
echo 'This command will make it to the history.'
echo 'This poor command will be forgotten.'
You can check your current options using setopt or specifically:
setopt | grep 'histignorespace'
So there are two ways how you can fix this - either by fixing your aliases to not start with space or, If you really don't want this functionality at all, by unsetting it in your ~/.zshrc like this:
unsetopt HIST_IGNORE_SPACE

alias in .bashrc using Mac OSX: command works on the command line but in an alias it doesn't work

I realise there are a few questions similar to this but nothing that fully addresses the issue I'm getting.
I'm writing a few alias' for terminal commands I often use.
$ cd ~/Documents/blah/blah/blah
This works as a terminal command, but when I try to turn this into an alias:
alias pie='cd ~/Documents/blah/blah/blah'
This doesn't work, -bash: cd: Documents/blah/blah/blah: No such file or directory
I'm storing the alias in .bashrc in my home directory. I'm using Mac OSX.
Anyone know why it would work as a straight command but not an alias?
Similarly, I use a vagrant machine, and I'd like the chain together two commands: one to ssh to vagrant and the other to open the shell:
alias vshell='vagrant ssh && python manage.py shell
But this doesn't seem possible, it only ever executes the first command, maybe because this takes a little longer to complete?
Thanks

Bash alias causing error "bash: cd: too many arguments" only when set in .bashrc

I have several bash aliases set in my .bashrc but they generate errors every time I open a new terminal. Each time a new terminal opens, two bash: cd: too many arguments will appear. The aliases work as intended, but I would like to solve the errors anyway. Here are the aliases in question:
alias .1="cd .."
alias .2="cd ../.."
alias .3="cd ../../.."
alias .4="cd ../../../.."
alias .5="cd ../../../../.."
alias .=".1" #Trouble maker
alias ..=".2"
alias ...=".3"
alias ....=".4"
alias .....=".5"
I have narrowed it down to alias .=".1" as the culprit creating the errors. I understand the . is its own command and I am slapping an alias on top of it. I am not sure this is the issue or not, but I have noticed when I remove this line the errors disappear. Furthermore, running the alias on the CLI itself does not generate the same errors... only when in the .bashrc does it generate the errors.
Things I have tried:
Quotations on both sides of =
Changing alias .=".1" to alias .="cd .."
Adding a space before alias command in an attempt to suppress output
Aliasing . means you are changing how subsequent shell commands include other shell scripts. Since . and source do the same thing in bash you might be able to fix this by making sure that they're only using source. Look in .bash_profile for instance. Bash looks at a variety of files while it is starting and .bashrc is probably getting read by .bash_profile and something in there is trying to . some other file.
But really, why? Can you just add a dot to each of these and be ok with it? The .. directory is one level up so that could make it easier to remember. Changing things like this that are fundamental to how the shell operates and glues together multiple scripts is going to keep tripping you up.
The alias that is causing the error is: alias .=".1". The single period is a synonym for the source command, which reads in and executes commands from the file you pass as its argument.
What you're essentially doing (unintentionally), is trying to change the behavior of the source command using an alias.

Unix bash alias not working after start screen

Hi I am having a problem with setting alias in mac after I start the screen command, I have alias for working with git, like
commit=git commit
they work as I expect when I start my terminal (iTerm2), but then sometimes I use screen to have simultaneous instances in remotes servers and virtual machines I work with. After this the alias disappear(command not found).
Does anyone know why or how solve it?
To make the alias work, you must use the alias command. For example, to create an alias in Bash you do:
$ alias commit="git commit"
This works temporarily ie.: in your current shell. In order to make it "stick", you must put it in your ~/.bashrc. That will make it be sourced to all instances of Bash you'll invoke during your terminal session.
When you start screen, it starts a separate Bash too, so you'll be covered.
You write something about VMs. If you need this alias to work there, you must make ~/.bashrc on these VMs to have the same aliases. But that's the other story. You should already know how to achieve what you want.
You need to make sure your aliases are defined in ~/.bashrc to ensure they get included in all logins. You can test this out: edit your ~/.bashrc to include this line:
echo "bashrc"
And then edit your ~/.bash_profile to include this line:
echo "bash_profile"
You'll see when you start screen that only "bashrc" is displayed.
See this question for much more detail on the subject.

How to run a script with Git bash with custom bashrc?

I am trying to get a bash script to run in git bash while specifying a different .bashrc than the one in my home directory (or none at all) however it is proving an impossible task.
To my understanding this should work:
"C:\Program Files (x86)\Git\bin\sh.exe " --rcfile .bashrc --login -i C:/Scripts/myscript.sh
However no matter what I try either the --rcfile file flag will be completely ignored or the script will get parse errors because it is not parsed by bash.
The following are my findings:
--login flag is needed to get the script to be parsed by bash rather than windows command prompt
--rcfile and also --norc are completely ignored if flags --login is used
I have tried every possible combination I think of, including calling the script within my .bashrc file, swapping the flags around, using the -c flag to run the script command and swapping my .bashrc files around to try using the --norc flag instead.
Is this just a result of shitty bash implementation for windows or am I doing something wrong?
Any help on the matter is appreciated.
You can try sourcing your .bashrc inside the script myscript.sh.
source .bashrc
Or
. .bashrc
As far as I can tell, the -i flag is overridden by the fact that you provide a script for bash to run. Your shell isn't actually interactive, so --rcfile is ignored. The only way I can tell to both run a script and source an additional file is to use a non-interactive login shell; however, in that case, you are restricted to using .bash_profile, .bash_login, or .profile, whichever is found first:
bash --login myscript.sh
There is no --loginfile to override the choice of file sourced prior to myscript.sh.
UPDATE: I forgot about BASH_ENV.
export BASH_ENV=.bashrc
bash myscript.sh
I do not know how you would go about adding BASH_ENV to your environment in Git bash.

Resources