I had an alias in my bash profile like this:
alias test='cd /Usr/work/dir/test'
every time I would try to use bash completion for git in a terminal it would:
freeze the terminal immediately after hitting tab.
take me to that directory.
As soon as I removed that alias bash completion for git works fine. Why's that?
git version 2.26.2
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Copyright (C) 2007 Free Software Foundation, Inc.
test is a built-in command, and creating an alias named test shadows it, which could lead to unforeseen issues. Pick a different name.
alias goto_test='cd /Usr/work/dir/test'
However, this is probably the least desirable solution. First, consider using a function instead:
goto_test () {
cd /Usr/work/dir/test
}
Second, you can add /Usr/work/dir to your CDPATH variable, so that you can quickly switch to any subdirectory without having to use the entire path.
$ CDPATH=/Usr/work/dir
$ cd test
/Usr/Work/dir
$ pwd
/Usr/Work/dir/test
This saves you from having to define multiple aliases or functions if there are several directories you might commonly switch to.
Related
I am on MacOS. I recently upgraded to Mojave. I'm running the Homebrew version of GNU bash, version 4.4.23(1)-release (x86_64-apple-darwin17.5.0).
When I open a new bash shell by issuing the bash command, I get the following error every time I issue a new command:
bash: parse_git_branch: command not found
The error is getting generated from the following line in my .bashrc file that customizes my command line with the git :
export PS1="\[\033[32m\]iMac5K# \[\033[33;1m\]\w:\[\033[m\]\[\033[33m\]\$(parse_git_branch)\[\033[00m\] "
(Note: my .bashrc file is sourced by my .bash_profile file.)
The parse_git_brach is in my .bashrc file so I'm not sure why I am getting this error. Even after I manually source .bashrc, I still get the error.
Issuing which bash yields:
/usr/local/bin/bash
Thanks.
When you just run bash without -l or -i, it doesn't execute .bash_profile or .bashrc itself, but only honors variables it received through the environment.
When you export a variable, you're exposing it to child processes... through the environment.
So, your child shell receives the PS1 definition, but it doesn't receive the function that PS1 requires!
You have some options here:
Export the function alongside the PS1 definition that uses it. That is, export -f parse_git_branch. This has an important caveat in that only shells which read exported functions (which is to say, in practice, bash) will get any benefit from this fix.
Stop exporting the PS1. That is, just take the export off the line PS1='...'.
Set BASH_ENV=$HOME/.bashrc and ENV=$HOME/.bashrc, which will instruct even noninteractive shells to run .bashrc (of course, this can change the way scripts execute, and is thus at a risk for causing bugs in other software; moreover, the latter means your .bashrc needs to be written to be safe for non-bash shells).
I installed Git For Windows 2.7.2 a few days ago. Now I have some problems with using optional tools Git For Windows provides from cmd.exe. In the previous version of Git For Windows(or say msysgit), I could configure these tools by modifying Git/etc/git-completion.bash. For example:
alias ls='ls --show-control-chars --color=auto'
I used this way to make ls display file names that contained Chinese characters normally. Now it seems this way doesn't work. In fact there is no git-completion.bash under Git/etc/. There is a git-completion.bash under the folder Git/mingw64/share/git/completion. I tried to copy it to Git/etc and add the alias above, which didn't work either. These tools only works fine in Git Bash. So how should I configure these tools together with git to use them from cmd.exe?
This answer explains why you no longer have this functionality. In short, msysgit provided a unix shell emulator, mingw. Git for Windows is git compiled in a Windows environment.
Therefore, ls is simply an alias for dir in a Windows shell, not mingw's ls. If you want to create some Windows aliases, you can use doskey. Here's an answer for that.
Alternatively, I would suggest that you just start using PowerShell, where you'll be able to set up the $profile variable with some powerful commands like these.
I have made a shell script to run as terminal command, but the cd commands inside it is not effective and hence I want to run it with source so that the cd commands take effect.
script name : "project.sh"
I added this file to /usr/local/bin, made it executable by chmod +x project.sh and it runs fine, but the cd command is not working.
I know it runs in a child process and hence at the end terminal returns back to the starting directory, rendering no effect of cd commands inside project.sh.
The solutions presented at Sol:1 do not work for me, because they asks me to run source <file>, which is not possible if I want to use it as Bash command.
You use the source command:
source /usr/local/bin/project.sh
There's no way to make this happen automatically by typing the script name, that always runs the script in a subprocess. If you don't want to have to type this all out, you could create an alias in your .bashrc to simplify it:
alias project='source /usr/local/bin/project.sh'
Then typing project will be translated to that full command.
Of course, source <file> is a Bash command - it uses the source builtin to run script <file> in the context of the current shell rather than in a child process, thus allowing commands in <file> to change the current shell's environment, such as in terms of the working directory (using cd).
Using source, or its alias ., is (ultimately) the only way to achieve that.
If your intent is not to have to invoke <script> explicitly with source, you have two options, both of which are best defined in your Bash profile, ~/.bash_profile (since you're on OS X; on Linux, use ~/.bashrc[1]):
I'll assume that your script is /path/to/foo, and that you want to invoke it sourced as just foo:
Option 1: Define an alias: alias foo='source "/path/to/foo"'
Option 2: Define a function: foo() { source "/path/to/foo"; }
Both aliases and functions execute in the current shell, allowing you to effectively hide the source call behind a single command; aliases are generally a little easier to define, but functions offer more flexibility.
By virtue of the alias / function being defined in your Bash profile, which itself is implicitly sourced, the commands in /path/to/foo will affect your interactive shells' environment.
Note: Either definition of foo will only be available in interactive shells (those that (automatically) source ~/.bash_profile).
Additional steps would be needed to make foo work inside non-sourced scripts as well, but at that point you should ask yourself whether you're obscuring things by not making the fact that /path/to/foo is getting sourced explicit.
If you're writing a script that must be sourced for distribution to others:
Install the sourcing command in the user's shell profile / initialization file (as described above) on installation of your script.
If there is no installation process (and also to enable on-demand installation in general), implement a command-line option for your script such as i (--install) that performs this installation on demand.
Preferably, also implement an uninstallation option.
Either way, build logic into the script so that it refuses to run when run without sourcing, and have the error message contain instructions on how to install sourcing.
See this answer for how to detect sourcing.
A real-world implementation of the above - although more elaborate due to being multi-shell - is my typex utility; source code here.
[1] On OS X, Bash instances started by Terminal.app are login shells, which means that the only (user-specific) file that is automatically sourced on startup is ~/.bash_profile.
By contrast, on most Linux systems Bash instances are non-login shells, where only ~/.bashrc is automatically sourced.
While it is common practice to source ~/.bashrc from one's ~/.bash_profile, this has to be configured manually and therefore cannot be relied upon blindly.
I'm experiencing the following behaviour in bash that I find very annoying:
Type export VARIABLE=~/
Now I'd like auto-completion for the next segment of the path, so I press <tab>.
Bash clobbers the VARIABLE=, leaving just export ~/.
Why is this happening?
My bash version is 4.3.33, OS is Debian testing, terminal is Konsole.
Verify that $COMP_WORDBREAKS includes an =. If not, try this:
COMP_WORDBREAKS+==
If the export completion works to your satisfaction after that, then you need to figure out what startup file is changing COMP_WORDBREAKS.
For example, if you've installed node.js, the npm completion script (in /etc/bash_completions.d/npm removes = and # from COMP_WORDBREAKS.
Many completion scripts, somewhat annoyingly, change global settings. (For example, the standard Debian/Ubuntu completion scripts enable the extglob shell option.)
I want to change the command so that command line flag(options) are placed before command line arguments, as which is done automatically by GNU getopt.
Mac use BSD getopt so that function is lacked. I want to tweak the bash so that upon executing of one command, I run a script that parse the flags and arguments reorder them and execute the reordered command.
In this way, both
ls -lh /tmp
ls /tmp -lh
will work in my Mac's terminal.
You can't safely write a general purpose tool to do the job of reordering arguments on a command line unless you know what the optstring argument to the getopt() function looks like for each command. Consider:
make something -f makefile
cp something -f makefile
In the first command, you have to move both the -f and makefile to the front to canonicalize the command invocation. In the second, you must only move the -f; if you move the following file name too, you rewrite the command and destroy your data.
Of course, you also have to know what the getopt_long() argument strings look like if the command takes long-form --force or --file=makefile style arguments too.
Frankly, you'd do better to use POSIXLY_CORRECT in your environment on Linux and forget about the insidious flexibility it provides, and learn to write your options before your arguments at all times. Your code will work across all Unix-like machines better if you do that.
You could install GNU software in some directory other than /bin and /usr/bin (e.g. /usr/gnu/bin and then ensure that you place /usr/gnu/bin on your PATH ahead of the system directories. There are pre-built systems like fink, too. However, that won't help with tools from Apple that don't have analogues from GNU. And there's a 'danger' that shell scripts you write will not be portable to other Macs that don't have the same setup that you do.