The title pretty much says is all. one of often used used folders in my fish terminal suddenly became highlighted in yellow. Most of it's sub folders are highlighted in yellow too. Not sure what happened.
it's on mac Yosemite
Fish shell highlighted those directories yellow because that directory's permissions is set so that everyone can read, write, and execute. Essentially fish shell is warning you that the directory has the least restrictive permissions in case you weren't aware.
For example, in this screenshot:
If I change the permissions for the directory "oranges" to everybody can read+write+execute (chmod 777 oranges/), then you can see fish shell adds the yellow highlight.
When I change the permissions to something more restrictive (chmod 775 /oranges), then the directory "orange" is no longer highlighted.
Here's a good explanation of file permissions and the command chmod for more detail.
When you say "highlighted" do you mean when running ls? Probably you have $LSCOLORS set to something ugly.
Here's how you can set it to something nice, in fish:
set -Ux LSCOLORS gxfxbEaEBxxEhEhBaDaCaD
which makes it look like so:
(Just run that command once, don't put it in a startup file or anything)
Related
The company I work for has a code repository deep within a folder structure, the path of which I have saved in a text file. As I was copying that path from notepad++ and pasting it into a cd command for the hundredth time after launching git bash I began to get the feeling that I was wasting time. Being the good programmer that I am, spending an hour researching how to do something programmatically is obviously preferable to doing something that takes four seconds over and over again. However I have been disappointed to find that all of the readily-available solutions offer one of two recommendations which both feel more like workarounds than an actual config change:
Create a shortcut and modify the "start in" field. This is not acceptable for me because I launch git from the start menu (windows key + type "git"). I don't want to add the extra steps of navigating to the folder where I created the shortcut. Even if I give the shortcut a unique name such as "stupidshortcutname", I am not able to access this shortcut by searching in the windows start menu.
Modify the Windows environment variable HOME. This is not acceptable because I still want cmd to launch in its default location of C:\Users\MyUserNameHere.
With some further research I also found the option of creating a file called .bashrc in my C:\Users\MyUserNameHere directory, and having this run cd <folder I want to go to>, but this still feels pretty hacky for something that I feel should be a configuration somewhere.
Git has its own config files, I would be shocked if none of them allowed for setting the location git will default to launching in. Am I out of luck and/or being too picky?
Create a batch file with name like LaunchGit.bat & write the following command:
start F:\Program" "Files\Git\git-bash.exe --cd=D:\your\deep\workspace\path
Now you can launch it from desktop or place it in your Git home directory (and launch from there)
This may not be the most perfect solution, but it will solve your problem.
And ofCouse this is just an idea and you can change/improve it.
Use git-bash configuration to change the directory, if this is what you want.
In ~/.bash_profile (create it if it does not exist), add
cd /path/to/git/repository
The reason to use ~/.bash_profile instead of ~/.bashrc is because the latter is read and executed when an interactive shell that is not a login shell is started (if exists).
I need your help with an access issue with neofetch on my macOS.
Here the thing, I recently install neofetch on my terminal (oh-my-zsh), it works but, between the firts line (last login) and the logo that displays :
mkdir: /Users/'MYUSERNAME'/.config/neofetch/: Permission denied
/usr/local/bin/Neofetch: line 4476:
/Users/'MYUSERNAME'/.config/neofetch/config.conf: Permission denied
And I don't know why, of course, I did many types of research on google before asking you.
Do you have an idea?
You need to change the permissions for your config directory:
sudo chmod -R 666 /Users/YOURUSERNAME/.config
666 means Read-Write for all users.
Doing the same as garritfra did but with that last directory line you have there worked for me on a windows 10 machine though. It may work for the mac as well?
sudo chmod -R 666 /Users/MYUSERNAME/.config/neofetch/config.conf
Replace MYUSERNAME with whatever is shown in the error.
I was having the same issue and was able to solve this in the following way:
Open up Finder
Reveal hidden folders & files by pressing CMD+>+SHIFT
Locate the .config folder and right click it and click 'get info'.
Under the sharing & permissions section click the small plus and just add the entire Administrators group and remember to change the permissions to read & write for the entire group.
neofetch
Here is a bulletproof one-liner that solves the issue:
sudo chmod -R 710 $HOME/.config
Execute this command in a terminal session.
After restarting your terminal or, alternatively, sourcing your shell configuration file (assuming you have added the neofetch command to that file) with:
source ~/.zshrc
(replacing ~/.zshrc with the path to your shell configuration file if you are using a different one), the error prompt should disappear.
Note that this only gives 'execute' permission to the 'group' class. There is no need, as the currently accepted answer suggests, to give 666 or 777 modes as that needlessly makes your system less secure (not to mention even no. octal figures such as 666 don't even work as they fail to give the required 'execute' permission, which requires an odd number bit).
Modes such as 730, 750, and 770 will work, but unless something changes in neofetch's future update that demands it, it is unnecessarily too generous and I wouldn't advise it.
Finally, there is absolutely no reason to give users in the 'other' class any permission to the ~/.config directory (unless you have a very compelling reason to), and hence the last permission bit (3rd digit in the mode represented by octal numbers) should always remain 0.
I was following a Git course on Udacity and we made some changes to our bash profiles.
Somehow my .bash_profile is now recognized as a Unix executable file rather than a TextEdit document. I can still use it as before, but it bothers me that this change has happened. More than anything I would also like to know what is going on under the hood.
Where on my computer (I'm running MacOS) is the data stored that this is an executable? It doesn't have a file extension so how does the computer know? I changed its 'open with' field found in the 'get info' window but it still identifies as an executable.
in unix each file has permission bits which you can see with ls -l. In this case the 'x' bit has been set which means the file is executable. To revert the file back simply execute chmod -x on the file and it will unset the 'x' permission flag making the file a text file.
I feel like I'm missing something very basic so apologies if this question is obtuse. I've been struggling with this problem for as long as I've been using the bash shell.
Say I have a structure like this:
├──bin
├──command (executable)
This will execute:
$ bin/command
then I symlink bin/command to the project root
$ ln -s bin/command c
like so
├──c (symlink to bin/command)
├──bin
├──command (executable)
I can't do the following (errors with -bash: c: command not found)
$ c
I must do?
$ ./c
What's going on here? — is it possible to execute a command from the current directory without preceding it with ./ and also without using a system wide alias? It would be very convenient for distributed executables and utility scripts to give them one letter folder specific shortcuts on a per project basis.
It's not a matter of bash not allowing execution from the current directory, but rather, you haven't added the current directory to your list of directories to execute from.
export PATH=".:$PATH"
$ c
$
This can be a security risk, however, because if the directory contains files which you don't trust or know where they came from, a file existing in the currently directory could be confused with a system command.
For example, say the current directory is called "foo" and your colleague asks you to go into "foo" and set the permissions of "bar" to 755. As root, you run "chmod foo 755"
You assume chmod really is chmod, but if there is a file named chmod in the current directory and your colleague put it there, chmod is really a program he wrote and you are running it as root. Perhaps "chmod" resets the root password on the box or something else dangerous.
Therefore, the standard is to limit command executions which don't specify a directory to a set of explicitly trusted directories.
Beware that the accepted answer introduces a serious vulnerability!
You might add the current directory to your PATH but not at the beginning of it. That would be a very risky setting.
There are still possible vulnerabilities when the current directory is at the end but far less so this is what I would suggest:
PATH="$PATH":.
Here, the current directory is only searched after every directory already present in the PATH is explored so the risk to have an existing command overloaded by an hostile one is no more present. There is still a risk for an uninstalled command or a typo to be exploited, but it is much lower. Just make sure the dot is always at the end of the PATH when you add new directories in it.
You could add . to your PATH. (See kamituel's answer for details)
Also there is ~/.local/bin for user specific binaries on many distros.
What you can do is add the current dir (.) to the $PATH:
export PATH=.:$PATH
But this can pose a security issue, so be aware of that. See this ServerFault answer on why it's not so good idea, especially for the root account.
oh my god...i faced a big problem...i was created a .bash_profile in ~ folder and then set paths there...bust the big problem is after restarting my bash i see that none of my commands work like LS and RM and etc...
now i dont know how to fix it...some one help me...i need my terminal as soon as possible...
Make sure you are appending to the existing $PATH.
PATH=$PATH:/Users/mthalman/bin
To prevent this happening in the future:
When I edit my environment files (including bashrc, profile, login, and others), I always try starting another shell before quitting my editing environment. This protects me from the possibility of breaking my environment so that I can't log in.
Make sure your PATH includes the usual bin directories: /bin and /usr/bin.
First I would rename ~/.bash_profile to ~/old.bash_profile.
Then open that up in TextEdit (as a plain text document) and verify how you have set your path.
If you would prefer to use vim/emacs/nano/whatever, the act of renaming the file will allow new terminal sessions to use default paths, so from the command line you should be mostly fine.
Then verify you haven't clobbered $PATH as suggested by #Mark Thalman, above.
If you are in a Terminal Window, simply add in the /bin and /usr/bin back in your PATH.
$ PATH="/bin:/usr/bin:$PATH"
That should allow all the basic Unix command to work once more. Or, you can use the full path name for commands:
$ PATH="" #Can't find nothin'
$ ls
bash: ls: command not found.
$ /bin/ls -a #This will work!
. .. .bash_profile foo bar
Don't Reset PATH in your .profile!
As you discovered, you should never reset PATH in your `.bash_profile. Instead, you should always append and prepend to it:
PATH="/usr/local/bin:$PATH"
PATH="$PATH:$HOME/bin"
The first line will prepend /usr/local/bin to PATH which means if a command is in /usr/local/bin and /usr/bin, the /usr/local/bin version will be executed. Many system admins will put alternative base system commands in /usr/local/bin. For example, on Solaris, they might put VIM in /usr/local/bin/vi, so when you edit a file, you're using the improved VIM and not the base VI.
The second line appends your $HOME/bin to the end of $PATH. That means if there's a /bin/ls and you have ~/bin/ls, the /bin/ls will be executed first.
Never set PATH from scratch because each Unix system might have commands that you to access elsewhere in the system. For example, your site might require you to use X11, so you want /usr/X11/bin in your PATH, or you have GIT installed under the /opt/git directory, and you'll need /opt/git/bin in your path.
Sometimes, base utilities like ls might be replaced with upgraded versions of these utilities. On Solaris, you have the base vi and ls command, Most users like the GNU ls command because it uses color and prefer VIM to plain VI. I would included these utilities in /usr/local/bin and prepend that to my PATH.
And now a Word from a Sponsor
As you probably discovered, Finder doesn't list hidden files. That's why you can't see .bash_profile in Finder. You can use some hacks to change this, but it requires you to type them into the terminal window.
I use a Finder replacement called Path Finder. It contains a lot of neat Power User things such as allowing you to see hidden files, treat Packages such as apps as directories, and be able to view protected directories if you have Administrator access. There's a built in terminal and GUI Subversion client.
It's not cheap ($40), but you can download for free and try it out for 30 days.
BTW, I have absolutely no relationship to Cocoatech except as a customer, and I make no money from people buying Path Finder. It's just a tool I use.