I'm using zsh on Mac OS 10.6.8.
So, all of a sudden one of my machines asks me for confirmation every time I rm.
Frankly, I hate this with an abiding passion. I've never had a problem with rm, and I don't need to debate the potentialities.
First thing I did was which rm, which reports rm: aliased to rm -i.
Now, I've hunted high and low for this alias. zshrc, .config (which I don't have), the default zshrc files: everywhere I can think of. No mention of aliasing rm anywhere.
Is there a simple way to determine where this alias is being configured? Or to list all locations where zsh might be looking for config lines?
Nope, there's no way to know which startup file an alias has been configured from, sort of searching them yourself.
The Z-shell startup files can be found here.
A comment for the question suggests /etc/profile; this is incorrect (unless you're sourcing it yourself), as /etc/profile is a Bourne-type shell startup file.
If you can't find the place it's sourced, you could unset the alias [bottom paragraph] in ~/.zshrc: unset rm. That should work provided it's done after the alias is set.
Related
Backup, first.
Before attempting to resolve this, people are worried about $PATH changes breaking things. Backup your path with echo $PATH > $HOME/bak/conf/path.bak and remember (don't put any raw files into the bak dir). Confirm your backup with cat $HOME/bak/conf/path.bak.
A minimal $PATH!
My desired path is /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin.
This is a minimalist path that should break nothing on most default Linux installs (Backup, first).
I have a huge $PATH that is completely useless (like 120 lines of $PATH--caused by WSL [more later]). So far, I only know how to add to path and remove single directories from $PATH via seg.
Sounds like it should pop right up on search engines. I have a headache in my eye--:
how do I set $PATH to a raw string or purge it so I can append from null?.
Bonus points for anyone who can tell me how to set $PATH from the contents of a file!?
Best guess:
import sys, sys.path.insert(0, '/your/path')--!NO This did not work!
Temporary workaround:
You can move the path to a neutral file (or use whatever means you know) and replace / with / and then use sed to cut the unwanted part out:
PATH=$(echo "$PATH" | sed -e 's/:\/tons:\/of:\/unwanted:\/garbage$//')
Make sure you put everything you don't want between s/ and $//').
Where is this long $PATH coming from?
Related question: How to remove the Win10's PATH from WSL --$PATH is inherited every time you re-launch or perform some other actions such as possibly changing users or environments.
Why is this question different:
As if there isn't enough typing, S.O. has a nuisance dialog that asks me to write and explain why purging $PATH is different from removing one directory/path from $PATH.
Because a punch in the face isn't a kick in the butt.
If I'm understanding your question, you simply want to know how to set your Bash PATH to a fixed string (or erase it completely) and have it persist across restarts of the shell?
If so, then I'll start off by saying that this isn't recommended as it will break other things. If not now, then later.
But if you really want to set the PATH to a fixed value every time Bash starts ...
Short answer first:
Assuming fairly "default" startup files (where ~/.profile sources ~/.bashrc):
Edit your ~/.profile (or ~/.bash_profile in the rare case it exists) and add:
# Remove entirely
unset PATH
export -n PATH
# Optionally
export PATH=/new/pathItem1:/new/path/Item2
Adding this to the bottom of the file should override any other PATH modifications done previously. However, future application installations can make modifications below that, therefore overriding it.
In a very rare case where you have an interactive Bash session that isn't startup by a login shell, you could also make the same modifications to ~/.bashrc.
(Not necessarily required if the modification is the last thing called during startup, but) make sure that there are no other PATH adjustments in your ~/.bashrc or ~/.bash_profile.
More explanation:
Where is this long $PATH coming from?
Your path in Bash in WSL can potentially come from a few sources:
WSL's init process sets a default PATH for the starting application (shell). This is currently (in WSL 0.70.8):
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib
Since this is done before your ~/.profile runs, there's no need to worry about disabling it.
As you've pointed out, WSL automatically appends the Windows path to the Linux path so that you can launch Windows executables. This can be disabled using the method in the question you linked, but it's not necessary if you simply want to override the entire PATH. Setting the PATH in your ~/.profile comes after WSL sets it for the initial process (your shell).
Bash itself has a built-in, default path that is hardcoded into it for "fallback" in case no other path is passed in. This rarely ever takes effect. Most Linux systems are going to set the PATH through some other mechanism, meaning the fallback never gets activated. A typical Linux system will set the default PATH via /etc/environment, but this isn't used under WSL since the init mechanism mentioned above is needed instead.
If using Systemd or another init system in WSL, then Bash (and other POSIX shells) will process /etc/profile and files in /etc/profile.d when starting. These files may contain PATH modifications. Again, since these come before your ~/.profile, (re)setting the PATH to a fixed value will override any of these settings.
Finally, your ~/.profile or ~/.bash_profile (for login shells) and ~/.bashrc (for interactive shells are read. Typically, PATH modifications in these files look something like:
export PATH="/new/path/item:$PATH"
This prepends to the path, making that new item take priority over the previous items.
However, leaving out the existing :$PATH part will simply set it to a string literal.
It should be obvious, but if you do this without including the "normal" OS paths, you will be unable to call any command that isn't built in to Bash already with specifying its fully qualified path. For instance, ls will fail. Note that you can still:
$ ls
ls: command not found
$ /usr/bin/ls
# works
Also note that ~/.profile is called for login shells. It is possible, however, to tell WSL to launch Bash without reading ~/.profile:
wsl ~ -e bash --noprofile
The resulting shell will still have the default WSL path in this case.
This question already has an answer here:
How to restore .bash_profile on a mac? None of my unix terminal are working [closed]
(1 answer)
Closed 2 years ago.
I receive this error message each time I launch terminal:
-bash: =/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin: No such file or directory
You have recently edited one of your shell's startup files and introduced an error.
Probably, ls -lart ~/.bashrc ~/.bash_profile ~/.profile will indicate which one -- if one or more is missing, that's no concern, we just want to see which one out of these you have edited recently. Examine the time stamps and try to remember what you did to change one of these files.
The error probably looks something like
$oopsPATH=/usr/local/bin:$PATH
where you meant to say
PATH=/usr/local/bin:$PATH
but without access to your files, we can't know what exactly is supposed to be there, or how you messed it up.
See also https://askubuntu.com/questions/198730/how-to-restore-bashrc-file/198740#198740
In the common case where you have messed up your PATH so that ls and other commands are unavailable (bash: ls: command not found), you can use the full path (/bin/ls pro ls, etc; though obviously, you have to know the correct path) at least until you can restore your configuration.
PATH=/usr/local/bin:/usr/bin:/bin
is probably a good crutch until you can find the correct default for your OS. You can type that at the prompt, or put it in one of your shell's startup files and start a new shell.
On many platforms, you can find the default user dot files in /etc/skel so if that's present (which unfortunately will not be true for Mac OS, but should be there on most Linuxes):
cp -b /etc/skel/.bash_profile $HOME/
will replace your (presumably broken beyond repair) .bash_profile with the system default one. (Omit the -b option if your OS doesn't have it, but then you'll want to back up your file manually before replacing it.)
Update: This fragment near the top of your .bash_profile is erroneous:
#loginPath
=/usr/local/bin:$PATH
Just take it out; it doesn't seem to do anything useful. There seem to be multiple additional fragments from the MacPorts installer which look wrong, too, but they are just comments. (Perhaps somehow they shouldn't be?)
It seems that you are missing a necessary PATH and that is why it is saying no such file or directory. If, for example, you get this error message when typing in python, it would mean either that (1) python isn't installed; or (2) python isn't on your system path.
Me:~ me$ cd desktop
Me:desktop me$ pwd
/Users/me/desktop
What is the correct way to force case sensitivity (so that cd desktop fails but cd Desktop goes to the correct directory)? I would assume there was a shopt for that but the manpage doesn't suggest any obvious option.
Sounds like filesystem in question is not case-sensitive -- see the first answer here to verify.
Case-sensitivity is an option of the file system, not of the shell. Therefore you cannot change this with a shell option.
(To understand why, just consider that it is possible to have case-sensitive and case-insensitive filesystems mounted at the same time. How would you handle this with a single shell option?)
I just installed GMT4 (Generic Mapping Tools) from MacPorts and have run into some serious issues with terminal...
When using the ls command in terminal I get the following:
-bash: ls: command not found
To fix this I've tried many things that I read many different places online. I've changed the following files to include /usr and /bin:
~/.bashrc
~/.bash_profile
~/.profile
Doing so gave me back the sudo command which I had previously lost.
However, I still am not able to use ls in a new terminal window without manually exporting the path("new session"). This has been causing problems when I'm running shell scripts that use system functions. So I'm starting to wonder what exactly those three files do and if maybe having three files doing the same thing is causing them to interfere with one another. If anyone can tell me where I need to add these PATHS that would be great; I dunno, maybe I can delete one of these files or something ELSE is conflicting. Right now I just run " export PATH=$PATH:/usr" in each new terminal window and it works for that session.
I'm running Mac OS X 10.6 on a early 2011 MacBook Pro with 4GB of RAM.
Background for those who are interested:
My end goal is to use Relax to model viscoelastic relaxation in a mid-oceanic ridge system to come up with some sort of constitutive law or power-relation between slip magnitude and the location of greatest tensional stress in the lithosphere due to normal faulting.
The Bash manual actually explains these files fairly thoroughly. However, the manual does not describe how these mechanisms are usually used in practice. What follows is a brief, abridged version of what is common best practice.
.profile is read at login by both sh and bash.
.bashrc is read by non-login Bash shells. By convention, .bash_profile sources .bashrc in turn.
.bash_profile is read at login by Bash. If this file exists, .profile is not read. By convention, .bash_profile should source .profile if it exists.
In bash, environmental variables will tab-expand correctly when placed after an echo command, for example:
echo $HOME
But after cd or cat, bash places a \ before the $ sign, like so:
cd \$HOME
If I use a variable as the second argument to a command, it won't expand at all:
cp somefile $HOM
What mysterious option do I have in my .bashrc or .inputrc file that is causing me such distress?
What you're describing is a "feature" introduced in bash 4.2. So you don't have any mysterious option causing you distress, but just "intended" behaviour.
I find this very annoying since I preferred it the way it used to be and haven't found any configuration options yet to get the earlier behaviour back. Playing with complete options as suggested by other answers didn't get me anywhere.
Try complete -r cd to remove the special programmatic completion function that many Linux distributions install for the cd command. The function adds searching a list of of directories specified in the CDPATH variable to tab completions for cd, but at the expense of breaking the default completion behavior.
See http://www.gnu.org/software/bash/manual/bashref.html#Programmable-Completion for more gory details.
For the second instance, you can press ESC before tab to solve it.
I don't know the solution to your problem, but you could look in /etc/bash_completion or the files under /etc/bash_completion.d to determine what commands use autocompletion and how.
help complete
Might also be helpful.
The Bash Reference Manual has more information than you might want on expansion errata.
Section 8.7 looks like it would be the place to start. It give information on the 'complete' function, among other things.
Check the answer for
https://superuser.com/questions/434139/urxvt-tab-expand-environment-variables by Dmitry Alexandrov:
This is about direxpand option. $ shopt -s direxpand and $FOO_PATH/ will be expanded by TAB.
I'm answering 4-year-old question! Fantastic!
This is a bash bug/feature which was unintentionally introduced in v4.2, and was unnoticed for a long period of time. This was pointed out by geirha in this tread. Confirmed as unintended feature here
I came across this problem when running Ubuntu at home. At work I have bash-3.00, so I've spent some time browsing around to see what's going on. I wonder if I can 'downgrade'....