I was trying to use gdb on a program earlier on a Linux 64-bit machine, and I ran gdb bomb (that's the program name), and within gdb, I simply typed in ran. It came back with the error /bin/bash: /home/imicrothinking/ics11302016004/lab2/bomb: No such file or directory During startup program exited with code 127.
I've dug around the net for a bit, and suggestions I've heard so far led to no concrete solutions, here's what I'm sure of so far:
I'm logged on as a root level user.
I haven't gone to the wrong directory.
The executable file definitely exists.
I'd welcome all suggestions.
maybe gdb cann't find your shell. so set the env var SHELL to your shell.
eg: export SHELL=/bin/bash
ref : http://www.linuxquestions.org/questions/linux-software-2/gdb-giving-wierd-error-169299/
Related
I'm running Ubuntu-20.04 through WSL2 on my Windows 10 laptop. I've started having an issue in VSCode where the integrated terminal isn't getting its $PATH initialized correctly.
If I open an Ubuntu shell through Windows Terminal and run echo $PATH I get the following output:
/home/<user>/bin:/home/<user>/.nvm/versions/node/v15.1.0/bin:/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin:/opt/devkitpro/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Common Files/Oracle/Java/javapath:/mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/mnt/c/Program Files (x86)/AMD/ATI.ACE/Core-Static:/mnt/c/Program Files (x86)/Calibre2/:/mnt/c/Program Files/Calibre2/:/mnt/c/Program Files/PuTTY/:/mnt/c/Program Files/FileBot/:/mnt/c/Users/<User>/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/<User>/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin
However once connected to WSL through VSCode if I run the same command in the integrated terminal I get:
/home/<user>/.local/bin
This means I can't even run the most basic commands like ls.
I can't understand why this is happening? Is there some setting in VSCode that would be interfering with my shell initialization, preventing $PATH from getting set correctly? I can't even run env to see what other environmental variables are doing.
The default shell in VSCode is set to bash.
It is my understanding that bash reads instructions from /etc/profile which sets shell variables. Could there be any reason these instruction are not being read?
Ok so I figured out what was causing the issue.
In my .bashrc, I had added the line:
export `PATH="/home/<user>/.local/bin"`
presumably to be able to access programs located there from any directory. For whatever reason this wasn't causing an issue when a shell was launched from Windows Terminal, but VS Code did not like it! Simply removing the aforementioned line from .bashrc solved the problem.
Guess I've got a lot to learn about .bashrc, .bash_profile, etc., and how these are accessed when starting up a bash shell. If anyone wants to shed light on this, feel free to comment below.
I installed Haskell on my MacOS system using ghcup installer. It worked because if I type ghci I am dropped into this interactive shell. However I got this message in the terminal after doing the install:
In order to run ghc and cabal, you need to adjust your PATH variable.
You may want to source '/Users/user1/.ghcup/env' in your shell
configuration to do so (e.g. ~/.bashrc).
Detected bash shell on your system...
If you want ghcup to automatically add the required PATH variable to "/Users/user1/.bashrc"
answer with YES, otherwise with NO and press ENTER.
YES
grep: /Users/user1/.bashrc: No such file or directory
My shell is bash 3.2 But as you can see, when I typed YES it says there is no such file. How do I find my shell configuration file, or resolve this? I'd like to complete the setup correctly here.
And I have to be honest about my level of knowledge here, I don't truly understand what this is asking exactly. Is the PATH variable 'env'?
On macOS, .bashrc does not exist by default. ghcup will create this file, so the command you ran will have worked correctly. However, one of ghcup's subcommands expected to find the file before it was created, and therefore reported that error message. You can safely ignore this.
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.
I am trying to use the shell command to facilitate commands like adding directories, etc. while in emacs. I am having problems getting it to work.
I enter M-! and then my minibuffer says Shell command: but none of my commands are accepted. For example, entering pwd or ls I get messages like pwd is not recognized as an internal or external command, operable program, or batch file.. Any suggestions?
I used this reference, but it does not seem to help with my situation:
http://www.nongnu.org/emacsdoc-fr/manuel/shell.html
Extra Info
I am using Windows 7 OS. I also have cygwin64 installed, if that matters. Is emacs just connecting to an external shell, or is the shell built into emacs? If the shell is external, can I connect to cygwin64 (although it may not be worth the trouble).
Any suggestions on how to configure this properly? I found the following resource, but I am not sure whether this is the right direction: http://www.emacswiki.org/emacs/EmacsApp
Sounds like you need to make sure that variable exec-path includes the directories where those commands (ls etc.) are located.
That error message does not appear to be an Emacs error message (from the Emacs Lisp or C source code), but rather it seems to come from the shell that tries to execute your command.
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703