Every time I try to run anything in GDB, I am met with the following error message:
Error: No such file or directory
During startup program exited with code 127.
Searching around on here, I found out that this can occur when the SHELL variable is not properly set, and indeed running export SHELL=/bin/bash --login before running GDB solves the problem for the current session.
However, this is in spite of the fact that echo $SHELL spits out the desired value already. If I look closer at the command GDB is trying to execute, it typically takes the form:
/path/to/mybin -c exec /path/to/mybin --my --opts
instead of
$SHELL -c exec /path/to/mybin --my --opts
That is, GDB somehow resets SHELL to point to whatever executable I am passing it before it starts running. (I use the format gdb --args /path/to/mybin --my --opts to start GDB.) Before and after the run, SHELL has the correct value. If I try to debug three different executables in a row, each of those three executable will be used as it's own shell, obviously producing failures. If I even once run export SHELL=(acceptable shell), it will work properly for the remainder of the session.
None of my shell dotfiles (.bashrc, .profile, etc) make any reference or modification to the SHELL variable. This behavior seems completely incomprehensible to me. Does anyone have an idea what may be going on?
I am using gdb-7.7.1 in bash-4.3.11 on Ubuntu 14.04.
EDIT: I was wrong about an important detail. Running export SHELL=/bin/bash --login actually does not correct it. The same problem persists if I do that. (This is also the default value in my shell and what I see if I enter show env SHELL when gdb is not working. However, setting export SHELL=/bin/bash does correct the issue, so the login shell is somehow the issue, I guess.
The problem is almost certainly with your ~/.bashrc but it's hard to guess what it is from your description.
Step 1:
mv ~/.bashrc ~/.bashrc.save.20170411
logout and back in verify that GDB works just fine
Step 2:
Copy parts of .bashrc.save.20170411 to ~/.bashrc, and repeat logout/login cycle, until GDB stops working again.
Step 3:
Now you know part is causing trouble, and can ask a better question if you still don't understand why that chunk of .bashrc is problematic.
Related
Please,
I have a terminal application that requires no echoing of control characters back to the terminal.
I can happily issue 'stty -echoctl' at a terminal, run my application and obtain the result I am after. Further, I can include 'stty -echoctl' in .bashrc and everything is fine. (I have also added it to .profile but that seems to bring in .bashrc anyway)
I can then open another terminal (type 'konsole/gnome-terminal/xterm' in the original console and again I get the result I expect.
The problem I have (and this is in preparation of forking the program form another application) is that if i try
$ xterm -e ./V2.13
or even
$ xterm -e bash -c ./V2.13
the control characters are in fact echoed back to my app.??
EDIT:Additionally is there any need (benefit) in executing bash to execute my application ?
I am trying to refresh my aliases on my Mac (OS Catalina 10.15.6) after defining new aliases in my .bash_profile file with the command:
source ~/.bash_profile
But terminal keeps giving this error message:-bash: s: command not found
This is confusing because for the longest time this command worked. I even had it included in my .bash_profile file as an alias, where it worked fine.
I'm aware the problem could have to do it with an error in my PATH but I've never made any edits to my PATH so have no idea what the issue could be?
Thanks in advance.
My first instinct would be to check both ~/.bashrc, and /etc/bashrc if it exists. That is where I customarily define aliases, and it looks to me as though a bad alias may be your problem.
I'm not saying it was the one you made, although it might be. Just go through your rc and profile files and look for any aliases which might in any way clash with source.
I suspect the source command is working just fine and the problem is a bad line in the ~/.bash_profile itself that looks like it's trying to run a command named s. I would look in there for the problem.
It might help to run it with xtrace on via bash -x ~/.bash_profile – running it in a separate process like that won't have any of the presumably-desired side effects of sourceing it in your current shell, but you can see what it's trying to do so that you can fix it.
(You can also just set -x before the source and get both xtrace and running in the current shell; just be sure to set +x afterwards or your shell session will be full of debug output.)
Recently I installed Zshell instead of Bash. During this, then I saw that my $PATH was 7 miles long, - so I decided to try and clean it up a bit. When I uninstalled rvm (by running rvm implode followed by rm -rf ~/.rvm) then when I restarted my terminal, I now see an error:
If I just press ENTER, then the error remains. But if I do any other command, then it disappears (ls, echo, source ~/.zshrc - you name it).
If I reboot iTerm (or start a new tab), - then the error re-appears.
The error is not being showed, - so if I activate another theme, then I can't see if there is an error.
My gut feeling tells me, that it has something to do with my path, but I'm not sure. My path is waaay shorter than before RVM was installed.
If i rename my ~/.zshrc-file, then the Powerline9k-theme gets deactivated, so I can't see if the error actually still appears or not. But I have tried it... Then a theme-less zshell just start up.
Any idea how to fix it or how to debug it?
EDIT
I just realized that it could actually have been a left-over-error, from back when I was running bash, - so I added that tag as well.
If the visual blemish disappears as soon as you execute any command as you say so, just place an echo -n at the end of your .zshrc as a quick and easy fix, if you are not up to the task of debugging and potentially causing more problems on your machine.
The issue isn't worth your time ;)
Edit: Apparently the above didn't work. See comments.
If you are interested in debugging, a good starting point would be to place set -xe (print every line that is executing and abort on any line that exits nonzero) at the beginning (after the shebang line, or as flags in the shebang) of each configuration script that is executed when you start a new interactive shell.
Also consider set -xeuo pipefail to additionally catch and abort on usage of unset shell variables and commands that return nonzero inside pipes (e.g. set -e will not abort on false | true because the overall line exited with status 0, but -o pipefail will abort on such a line). It is worth noting that these flags are bash features, but since zsh is a feature superset of bash, they work in zsh too.
Have look at their documentation on github, relevant fragment is here.
Solution:
In your ~/.zshrc find variable called POWERLEVEL9K_LEFT_PROMPT_ELEMENTS and remove rbenv.
Explanation:
The default value of POWERLEVEL9K_LEFT_PROMPT_ELEMENTS is (context dir rbenv vcs), and it is likely that rbenv is the segment producing the error - after you uninstalled rvm that segment can't execute.
Uninstall all apps that use the path and reinstall. It's the only way. Instead of rm, you use should create an alias that has a trash can.
I am trying to run the following:
source activate env-name
But I am receiving an error that tells me that the call to activate must be sourced. In the Conda activate script, there's an if block near the beginning that tests "$(basename "$0")", specifically whether it's equal to activate, in which case it will raise the exception I'm referring to. A little bit of fiddling with the script (i.e., echo $0; return 1) and I found out that it does indeed think that the 0th argument that I am passing in is activate rather than source. This is perplexing because I know that my command includes source in it and that that should be the 0th argument. I'm not sure what else there is to do. Does anybody have any clues?
In case it's important, I am using zsh as my default shell and it seems that the activate script is a bash script, but I don't think that should matter (it doesn't elsewhere for me, only in this specific environment on my work laptop). I am able to get around this whole thing by just commenting out the whole check (and a couple of other minor changes), but I'd rather not have to do that in this particular case.
I've been having the same issue, the only workaround I've found is:
source <PATH TO ANACONDA>/anaconda3/bin/activate <ENV NAME>
EDIT: adding the line:
export PATH=$PATH:<PATH TO ANACONDA>/anaconda3/bin:$PATH
to your bashrc (or zsh etc) will add source to your path and you will be able to use source as normal.
** I DON'T HAVE ENOUGH REPUTATION, SO I REPLY THIS. (I wanna just comment but I can't)
It can be solve that you know this.
"Run 'Source activate envname'" means you have to run this command on correct path or directory.
If you install anaconda3 on /home/user/anaconda3/
your correnct source path is /home/user/anaconda3/bin/
/home/user/anaconda3/bin/ activate tensorflow
or
cd /home/user/anaconda3/bin
. activate tensorflow
So, I already solve this problem through adding path(or move correct path)
I got similar error because I was using asdf-vm which masks actual binaries with shims. As documented here, scripts that need to be sourced must be accessed directly because asdf uses exec system call. So in my case, the following command worked:
source $(asdf which activate) <ENV NAME>
While this answer is specific to asdf, the error you're getting suggests you were in a similar situation where the call to activate was intercepted by some other executable.
I was trying to get a crontab working on my Raspberry PI and I think I messed up my environment variables. I can execute a file from the GUI by right-clicking and choosing execute. However I cannot get the same file to run from command line. I can use ls to see the file (ChromeTab.sh), but when I type ChromeTab.sh, I get "bash: ChromeTab.sh: command not found".
I think I messed up my environment variables when I put this in the crontab.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
I followed the examples in Script doesn't run via crontab but works fine standalone.
Any idea what I'm doing wrong?
UPDATE:
OK,
Let me clarify what efforts I took on my part BEFORE posting my question on stackoverflow before getting anymore downvotes.
First of all thanks S. Adam Nissley for your suggestions.
In answer to your steps listed above.
Running this from home path, or fully qualified path does Not work as stated.
Error: bash: ChromeTab.sh: command not found
./ChromeTab.sh
I have also ensured read/write and execute permissions on the file with
chmod +x ./ChromeTab.sh
Also, my bash script starts off with the following shebang
#!/bin/sh
So, what i'm trying to say is, regardless of using crontab or not the issue at hand is that I can not even execute the script from command line. This started happening after I was messing around with the environment variables in the crontab. I'm looking for a way to revert to the situation where I can at least run/execute bash commands from the terminal.
The only way I can effectively execute this script is (right-click execute) through the GUI.
Assuming you are in the same directory as your script, you should just be able to enter
./ChromeTab.sh
If it does not execute, make sure it is executable with the command
chmod +x ./ChromeTab.sh
Or
chmod 755 ./ChromeTab.sh
And if it still won't execute, make sure it has an appropriate hashbang on the very first line of the script like #!/bin/sh or #!/bin/bash
When you add it to your crontab, make sure it has the full path like
/home/pi/bin/ChromeTab.sh <br/>
EDIT: Default PATH and SHELL for Raspbian
You can check your PATH and SHELL environmental variables from the command line as follows:
echo $SHELL
echo $PATH
The default PATH for Rasbian is:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
And the default SHELL is:
/bin/bash
So if you need to set those it is as simple as:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
SHELL=/bin/bash
If you are having other issues with your environment, you may want to disable some of your local settings to see if the problem is in your profile. You can list all files with ls -a, which includes hidden files. Raspbian typically has a .bashrc and a .profile in each user's home directory. To disable them simple rename them:
mv .bashrc .bashrc_disabled
mv .profile .profile_disabled
If that solves the problem, you can inspect the files and make the necessary corrections before renaming them back to their original names.