After recent upgrade of Fedora 30 -> Fedora 31 I'm observing that when I launch a terminal from within VSCode for the project that I'm working on, I see this message:
bash: sed: command not found
~/data/Programming/JS/React vgorcinschi $
It is complaining about sed because I have a script in ~/.bashrc that tries to include in PS1 information about git branches:
# somewhere in ~/.bashrc
parse_git_branch() {
git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
export PS1="\[\033[32m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\] \u $ "
If, within the same terminal, I do man sed it will complain in the same manner about man. If I open a system terminal and navigate to the same location my path would look like this:
~ vgorcinschi $ cd ~/data/Programming/JS/React
~/data/Programming/JS/React (ch14) vgorcinschi $ echo $PATH
./node_modules/.bin:/home/vgorcinschi/.nvm/versions/node/v10.6.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/vgorcinschi/.local/bin:/home/vgorcinschi/bin:/home/vgorcinschi/.local/bin:/home/vgorcinschi/bin:/usr/local/java/jdk1.8.0_231/bin:/opt/maven/bin:/snap/bin
NB Note how sed works from within the same directory.
Repeating echo $PATH from VS Code terminal yields just this: /home/vgorcinschi/data/Programming/JS/React/node_modules/.bin
I think this question may come-up so these are the contents of my ~/.config/Code/User/settings.json:
{
"git.enableSmartCommit": true,
"metals.javaHome": "/usr/local/java/jdk1.8.0_231",
"window.zoomLevel": 0,
"terminal.integrated.shell.linux": "/usr/bin/bash",
"editor.tabSize": 2,
"editor.detectIndentation": false,
"terminal.external.linuxExec": "bash"
}
The following could also be very important. The directory above is on a partition which is on HDD (/dev/sdb1) , my ~/.bashrc and ~/.bash-profile are on a SSD (/dev/mapper/fedora-home).
If I open an empty directory with VS Code on the main partition (on SSD) I don't have this issue with the Code's terminal. But I didn't have it on the other partition either before the upgrade - this was just two days ago.
So I am not sure what is the issue really due to, but hopefully someone could help me with it.
Update [2020.10.30]
.node_modules appear on the path inside VSCode terminal because of these lines in ~/.bashrc:
if [ -d "$PWD/node_modules/.bin" ]; then
PATH="$PWD/node_modules/.bin"
fi
VS Code version
Version: 1.50.1
Commit: d2e414d9e4239a252d1ab117bd7067f125afd80a
Date: 2020-10-13T14:44:48.716Z
Electron: 9.2.1
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Linux x64 5.8.15-101.fc31.x86_64
Well that's embarrassing. As it becomes obvious from my latest description update I was re-setting the PATH once ~/.node_modules were in a sub-directory. So A solution was to add as a suffix the existing PATH in the if block:
if [ -d "$PWD/node_modules/.bin" ]; then
PATH="$PWD/node_modules/.bin:$PATH"
fi
Since I haven't played with ~/.bashrc in a while, I have no idea how did it use to work before.
Related
I installed ubuntu 18.04 on hyper-v using the quick create.
I am trying to set a environment variable that will take effect everytime I log in.
I put the following line:
export BOOST_ROOT=$HOME/boost_1_69_0
in each of:
~/.profile
~/.bash_profile (did not exist by default)
one at a time, followed by a log out and a log in.
I then opened a new terminal and issued:
echo $BOOST_ROOT
The output was a blank line. What am I doing wrong?
If I put it in ~/.bashrc it takes effect, however from what I understand, that is only for new bash terminals and won't take effect for anything that doesn't run in bash, right?
I was asking because gnome-terminal has an option (in right-click -> preferences) to treat the shell as a login shell.
If you do not want to mess with that, you could just do this in ~/.profile (be sure to remove ~/.bash_profile):
# if running bash
if [ -n "$BASH_VERSION" ]
then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]
then
. "$HOME/.bashrc"
fi
fi
This is what my Linux Mint distribution does (and ~/.bashrc doesn't contain much more than just this).
I'm currently using zsh with oh-my-zsh, and I've run into an annoying shell behaviour.
I must have done a subtle yet breaking change in the $PATH export while editing my .zshrc, because the following thing happens:
At the shell prompt while in ~/, issuing, for example, the flutter command...
$ flutter
...results in:
$ ~/flutter/
(as if calling $ flutter had been interpreted as $ cd flutter)
However, issuing $ flutter in any other directory, including $ ~/flutter results in the correct execution of the flutter command. Same thing for go and others.
Line 2 on my .zshrc exports $PATH in the following fashion:
export PATH=$HOME/bin:$HOME/.emacs.d:$HOME/flutter/bin/cache/dart-sdk:$HOME/flutter/bin/cache/dart-sdk/bin:$HOME/.pub-cache/bin:$HOME/.composer/vendor/bin:$HOME/.cargo/env:$HOME/.platformio/penv/bin:$HOME/flutter/bin:$PATH
I've been comparing .zshrc versions with other backups, and I may be missing something, but no differences were found.
What seems off, in your opinion?
If you've encountered this annoyance before, how did you correct it?
Explanation
It'a feature called AUTO_CD.
AUTO_CD (-J)
If a command is issued that can’t be executed as a normal command, and the command is the name of a directory, perform the cd command to that directory.
http://zsh.sourceforge.net/Doc/Release/Options.html#Changing-Directories
AUTO_CD is enabled by oh-my-zsh in file oh-my-zsh/lib/theme-and-appearance.zsh.
...
setopt auto_cd
setopt multios
setopt prompt_subst
[[ -n "$WINDOW" ]] && SCREEN_NO="%B$WINDOW%b " || SCREEN_NO=""
...
Solution
Append the following command in ~/.zshrc after oh-my-zsh is loaded to disable this feature.
unsetopt AUTO_CD
I've created a npm module that I intend to publish, but not without testing that it works first. So I install the module I'm working with, npm install -g . and it works well on my Windows computer, but it won't run on my Linux (Debian) computer. Instead I get the following error:
15:52 $ transval
: No such file or directory
The only thing I've found so far when I compare the generated cmd and bash file on my windows computer is that whilest (when comparing to, say, 'gulp') the cmd-files are identical in structre the bash files are not. The second line, where the basedir is set differs. This the full output of the published bash file for my module:
#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
case `uname` in
*CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac
if [ -x "$basedir/node" ]; then
"$basedir/node" "$basedir/node_modules/transval/bin/transval.bin.js" "$#"
ret=$?
else
node "$basedir/node_modules/transval/bin/transval.bin.js" "$#"
ret=$?
fi
exit $ret
But if I compare the top two lines with any other file there is a significant difference! This is the top two lines from any other module, such as gulp:
#!/bin/sh
basedir=`dirname "$0"`
All other bash files get that dirname. If I change my bash file to that basedir it all of a sudden works. It is driving me mad!
EDIT:
These two files are created when I run the command npm install -g . (thus installing my package globally for testing) or when I have published (i.e. npm publish), so I'm not generating these files my self.
My package.json has a bin entry which points at a file that looks like this:
#!/usr/bin/env node
var app = require('../bundle.js');
app.init(process.argv);
Anyone have any idea why it would work on Windows and not in Linux?
Ok, found the problem. It seems to have been a problem with publishing from Windows. Once I had published from Linux (Ubuntu in this case) I could install it on both Linux and Windows computers.
I'm not sure what the reason for this is, be it some npm bug or an issue with doze line breaks, but now it's working :)
I did try to publish previously from Linux, and failed, but with an old version of Node (4.something) and that didn't work but now I've upgraded to the latest version and it works well, so that might've had something to do with it.
Edit:
I can now verify that publishing on a Debian machine running node 6.2.2 creates an unusable published version whereas publishing on a Ubuntu machine running node 7.4.0 works well and can be installed and run anywhere. Both machines are running npm version 4.0.5.
Edit Per additional information in the OP's answer, it is indeed a line-ending problem. The problem actually is not related to $() vs. ``.
When generating on Windows, the lines end with a carriage return and a linefeed, \r\n. However, when running the generated script on Debian, only the \n is taken as the end of line. As a result, the assignment to basedir is effectively:
basedir=$(dirname "...")$'\r'
# ^^^^^ Carriage return! Oops!
I think that is why the error message was ': No such file or directory': before the :, the contents of $basedir were actually printed, ending with the \r. The \r moved the cursor back to the beginning of the line, then the rest of the error message, beginning with :, overprinted the path. (That's a guess, though — I can't reproduce the exact error message on my system.)
A workaround is to put a # (space-hash) after the basedir assignment:
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')") #
# add these ^^
That way the \r will be part of a comment and not part of basedir.
Note: see this question and its answers for other ways of getting $basedir.
Per chat, the OP is going to add the $basedir values for both options tomorrow.
For reference, here's where we are at present:
Per this answer, npm generates the wrapper scripts based on bin entries in the package.json.
npm uses the cmd-shim module to make the scripts.
cmd-shim was updated 2013/10/28 to use the dirname ... echo ... sed sequence so that it would work on msysgit.
gulp and other scripts using dirname "$0" were presumably generated with a cmd-shim predating that update.
The OP's Debian /bin/sh is apparently dash (currently 0.5.7-4 in debian stable).
for the OP, on Debian, bash is version: 4.3.46(1)-release and sed is version 4.2.2
I tried both basedir types on my Cygwin dash 0.5.8-3 and they both worked.
On Ubuntu, the OP has a different problem: /usr/bin/env: 'node\r': No such file or directory. That looks like a line-ending issue to me, probably different from the Debian issue.
I have followed a tutorial to install JDK 8 on my computer Centos7 OS, but in the last part I tried to set environment varibles.
In the last part of the tutorial I typed:
echo “export JAVA_HOME=/opt/jdk1.8.0_101” > /etc/profile.d/jre.sh
echo “export JRE_HOME=/opt/jdk1.8.0_101/jre” >> /etc/profile.d/jre.sh
echo “export PATH=$PATH:/opt/jdk1.8.0_101/bin:/opt/jdk1.8.0_101/jre/bin” >> /etc/profile.d/jre.sh
and then I am seeing this when I open the terminal:
bash: $'\342\200\234export':order not found
bash: $'\342\200\234export': order not found
bash: $'\342\200\234export': order not found
[evconsul8#localhost ~]$
Path:
[evconsul8#localhost ~]$ echo $PATH
/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/evconsul8/.local/bin:/home/evconsul8/bin
After that I Trying to search the cause open
~/.bash_profile
[root#localhost evconsul8]# gedit ~/.bash_profile
Result:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export JAVA_HOME=/opt/jdk1.8.0_101
export JRE_HOME=/opt/jdk1.8.0_101/jre
export PATH=$PATH:/opt/jdk1.8.0_101/bin:/opt/jdk1.8.0_101/jre/bin
export PATH
Note: In one of my attemps after the error I added manually the lines corresponding to JAVA_HOME, JRE_HOME and PATH=$PATH in the file above. It was ok??
The principal problem I guess it is causing troubles to other apps in my machine.
You should use regular double quotes (") to enclose a string and not the fancy ones (“) you are using.
I'm unable to use ls, bash.. any popular commands that are critical after changing the path.
I'm unsure what it was before (because I can't do vi command either).
I ran the first command, and realized the first one had a typo - not PATH, but I've typed PATh.
So I immediately ran the next one:
export PATH="/usr/local/bin:$PATh"
export PATH="/usr/local/bin:$PATH"
Then vi, ls, bash commands started to not work.
I did echo $PATH to see the PATH.
usr/local/bin:/usr/local/bin:/usr/local/bin:/usr/local/bin:
This is what I got. Any help is appreciated.
You should be able to source /etc/profile to reset your PATH variable, though it may step on a few other variables you've configured along the way. You could also just grep for the appropriate line from that to set PATH and redo that in your current environment
Also, you can always specify the full path to an executable you need in the interim. For example, if you wanted to use grep with the PATH in its current state you could use /bin/grep (or perhaps /usr/bin/grep depending your system)
1 > Try to load default .profile script
$ /bin/bash ./.profile
2 > Just Logout from current session
and Re-login it.
It appears you have "broken" your bash shell ~/.bash_profile script, because of the PATh typo. (The question explicitly states bash, so I'm answering in that context.)
Since the PATH is "broken", you will need to access your editor by using its fully qualified path.
/usr/bin/vi ~/.bash_profile
That should allow you to fix the PATh to be PATH.
If you find that you need to edit your PATH environment variable a lot, this little bash function can be helpful.
vipath() {
local tmpfile=$(mktemp /tmp/vipath-edit.XXXXXX)
echo "$PATH" | tr ':' '\n' > "$tmpfile"
vi "$tmpfile" && PATH=$(paste -s -d ':' "$tmpfile")
rm "$tmpfile"
}
Note: there are better ways to ensure the $tmpfile gets deleted that I did not use in this snippet. And on a multiuser system, there are better ways to make sure the temporary file is not located in a shared location.
If you want to add a directory location to your PATH, without adding duplicate locations, this little bash function can be helpful to prepend a directory location.
pathadd() {
if [ -d "$1" ] && [[ ! ":$PATH:" =~ ":$1:" ]]
then
PATH="$1:$PATH"
fi
}
I had the same in RHEL8, I did an export PATH for a certain directory and then no command worked anymore. I performed a faulty export PATH command probably.
I got messages like this:
>$ yum
bash: yum: command not found...
Install package 'yum' to provide command 'yum'? [N/y] n
Luckily I had some other similar systems where I could get the path from, so I did:
export PATH=/home/USER/.local/bin:/home/USER/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbine
Change USER to your own.
To make it permanent: add to $HOME/.bashrc with:
export PATH=$PATH:<YOUR PATH HERE>
When you do export PATH="/usr/local/bin:$PATH" you are saying, set PATH to /usr/local/bin: plus whatever was in the PATH variable before. This essentially concatenates the string "/usr/local/bin:" with the old path. That is why your PATH repeats so much, you must have run that command a few times.
Try running this: export PATH="/usr/local/bin".