I have a crash dump that I want to analyse with GDB on different computer. Crashed application uses several shared libraries (*.so files). I want GDB to load symbols from some of them but I can't put all of them in the original path.
Adding LD_LIBRARY_PATH to the environment doesn't help when working with dumps. When I type info shared it shows full (non-relative) paths:
(gdb) info shared
From To Syms Read Shared Object Library
0x00007fad4fb7f220 0x00007fad4fb80179 Yes /lib/x86_64-linux-gnu/libdl.so.2
...
No /opt/app/libXXX.so
...
How to specify different path for the example libXXX.so (from gdb command line or command prompt)?
The set solib-search-path option is for that purpose. Documentation says it is ment for using with gdbserver but also works with dump analysis. By default, it is set to ., so the directory that gdb is run from.
BUT: for some reason it doesn't work out of the box (at least with gdb 10.2). I don't know the reason, but I know a workaround: just type set solib-search-path . as a first command after entering gdb prompt. The output is following for me:
(gdb) set solib-search-path .
Reading symbols from /home/example/path/libXXX.so...
Of course one can type any path she want instead of ..
When running scripts in bash, I have to write ./ in the beginning:
$ ./manage.py syncdb
If I don't, I get an error message:
$ manage.py syncdb
-bash: manage.py: command not found
What is the reason for this? I thought . is an alias for current folder, and therefore these two calls should be equivalent.
I also don't understand why I don't need ./ when running applications, such as:
user:/home/user$ cd /usr/bin
user:/usr/bin$ git
(which runs without ./)
Because on Unix, usually, the current directory is not in $PATH.
When you type a command the shell looks up a list of directories, as specified by the PATH variable. The current directory is not in that list.
The reason for not having the current directory on that list is security.
Let's say you're root and go into another user's directory and type sl instead of ls. If the current directory is in PATH, the shell will try to execute the sl program in that directory (since there is no other sl program). That sl program might be malicious.
It works with ./ because POSIX specifies that a command name that contain a / will be used as a filename directly, suppressing a search in $PATH. You could have used full path for the exact same effect, but ./ is shorter and easier to write.
EDIT
That sl part was just an example. The directories in PATH are searched sequentially and when a match is made that program is executed. So, depending on how PATH looks, typing a normal command may or may not be enough to run the program in the current directory.
When bash interprets the command line, it looks for commands in locations described in the environment variable $PATH. To see it type:
echo $PATH
You will have some paths separated by colons. As you will see the current path . is usually not in $PATH. So Bash cannot find your command if it is in the current directory. You can change it by having:
PATH=$PATH:.
This line adds the current directory in $PATH so you can do:
manage.py syncdb
It is not recommended as it has security issue, plus you can have weird behaviours, as . varies upon the directory you are in :)
Avoid:
PATH=.:$PATH
As you can “mask” some standard command and open the door to security breach :)
Just my two cents.
Your script, when in your home directory will not be found when the shell looks at the $PATH environment variable to find your script.
The ./ says 'look in the current directory for my script rather than looking at all the directories specified in $PATH'.
When you include the '.' you are essentially giving the "full path" to the executable bash script, so your shell does not need to check your PATH variable. Without the '.' your shell will look in your PATH variable (which you can see by running echo $PATH to see if the command you typed lives in any of the folders on your PATH. If it doesn't (as is the case with manage.py) it says it can't find the file. It is considered bad practice to include the current directory on your PATH, which is explained reasonably well here: http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html
On *nix, unlike Windows, the current directory is usually not in your $PATH variable. So the current directory is not searched when executing commands. You don't need ./ for running applications because these applications are in your $PATH; most likely they are in /bin or /usr/bin.
This question already has some awesome answers, but I wanted to add that, if your executable is on the PATH, and you get very different outputs when you run
./executable
to the ones you get if you run
executable
(let's say you run into error messages with the one and not the other), then the problem could be that you have two different versions of the executable on your machine: one on the path, and the other not.
Check this by running
which executable
and
whereis executable
It fixed my issues...I had three versions of the executable, only one of which was compiled correctly for the environment.
Rationale for the / POSIX PATH rule
The rule was mentioned at: Why do you need ./ (dot-slash) before executable or script name to run it in bash? but I would like to explain why I think that is a good design in more detail.
First, an explicit full version of the rule is:
if the path contains / (e.g. ./someprog, /bin/someprog, ./bin/someprog): CWD is used and PATH isn't
if the path does not contain / (e.g. someprog): PATH is used and CWD isn't
Now, suppose that running:
someprog
would search:
relative to CWD first
relative to PATH after
Then, if you wanted to run /bin/someprog from your distro, and you did:
someprog
it would sometimes work, but others it would fail, because you might be in a directory that contains another unrelated someprog program.
Therefore, you would soon learn that this is not reliable, and you would end up always using absolute paths when you want to use PATH, therefore defeating the purpose of PATH.
This is also why having relative paths in your PATH is a really bad idea. I'm looking at you, node_modules/bin.
Conversely, suppose that running:
./someprog
Would search:
relative to PATH first
relative to CWD after
Then, if you just downloaded a script someprog from a git repository and wanted to run it from CWD, you would never be sure that this is the actual program that would run, because maybe your distro has a:
/bin/someprog
which is in you PATH from some package you installed after drinking too much after Christmas last year.
Therefore, once again, you would be forced to always run local scripts relative to CWD with full paths to know what you are running:
"$(pwd)/someprog"
which would be extremely annoying as well.
Another rule that you might be tempted to come up with would be:
relative paths use only PATH, absolute paths only CWD
but once again this forces users to always use absolute paths for non-PATH scripts with "$(pwd)/someprog".
The / path search rule offers a simple to remember solution to the about problem:
slash: don't use PATH
no slash: only use PATH
which makes it super easy to always know what you are running, by relying on the fact that files in the current directory can be expressed either as ./somefile or somefile, and so it gives special meaning to one of them.
Sometimes, is slightly annoying that you cannot search for some/prog relative to PATH, but I don't see a saner solution to this.
When the script is not in the Path its required to do so. For more info read http://www.tldp.org/LDP/Bash-Beginners-Guide/html/sect_02_01.html
All has great answer on the question, and yes this is only applicable when running it on the current directory not unless you include the absolute path. See my samples below.
Also, the (dot-slash) made sense to me when I've the command on the child folder tmp2 (/tmp/tmp2) and it uses (double dot-slash).
SAMPLE:
[fifiip-172-31-17-12 tmp]$ ./StackO.sh
Hello Stack Overflow
[fifi#ip-172-31-17-12 tmp]$ /tmp/StackO.sh
Hello Stack Overflow
[fifi#ip-172-31-17-12 tmp]$ mkdir tmp2
[fifi#ip-172-31-17-12 tmp]$ cd tmp2/
[fifi#ip-172-31-17-12 tmp2]$ ../StackO.sh
Hello Stack Overflow
So, I tried searching all over the web, how to make Command Line prefix, but can't find anything. What I mean by Command Line prefix, I mean RandomPrefix arg1 arg2 in CMD/Terminal. For example: node index.js, node is Command Line prefix, pip install blabla, pip is command line prefix. Well, that's command line prefix for me at least.
Elaborating a little bit on Stephan's answer, if you have an executable (i.e., a .exe), you can create a "Command line prefix" by adding it to your PATH (in Windows). After that, whenever you're in your console (cmd), the program will be triggered when your write it's name (e.g. if your executable is hello.exe, then you'd execute it by typing hello), and you can pass arguments to it if the program at hand receives any arguments upon launch. For adding your executable to your PATH in Windows 10: Press Win+X, then Y, then search for Environment variables and click the option that says Edit environment variables for your account. either in System variables or User variables, search for Path, click on Edit and add the location of the folder where your executable is.
If you're in Linux, you can add some alias for executing your program inside .bashrc: alias <command>='<path_to_command>'.
The "Prefix" is actually the name of the executable, e.g. - for windows - a myprog.exe called through myprog arg1 arg2. You define the name of the executable when you link your program:
g++ main.cpp -o myprog
I have an executable, which I can read symbols from (so it seems.) My problem is this: when it comes time to run, I get the following error:
(gdb) run
Starting program: /home/usr/src/etcetera/etcetera/bin/theExecutable.exe
Cannot exec -c exec /home/usr/src/etcetera/etcetera/bin/theExecutable.exe.
Error: No such file or directory
During startup program exited with code 127
obviously, I have edited the directories here. I searched how to fix this on SO, and tried some of the following solutions:
GDB cannot see source file
GDB can't find source file
GDB won't load source file
got onto this link:
https://sourceware.org/gdb/download/onlinedocs/gdb/Source-Path.html#Source-Path
and am trying to change the source file directory. (The source files are not in the same location as the executable, but instead are spread over a range of different places.) Unless I am mistaken, the way of doing this is to go:
(gdb) directory /home/usr/src/etcetera/etcetera/rootDirectoryForSourcefiles
and have the GDB search this directory. I have even tried changing directory into the source directory, and then running but still, it wants to try where the executable lives.
Am I completely missing the mark here in an obvious way, or is this likely to be quite obscure?
You are barking up the wrong tree. You problem has ~nothing to do with source files, and everything to do with your executable file.
It may be related to something in your ~/.gdbinit, or your ~/.bashrc, or the way you invoked GDB.
You should start by doing a basic sanity check:
env SHELL=/bin/sh gdb -nx /bin/date
(gdb) run
If that doesn't work, your GDB installation is screwed up.
If that does work, one of the three things I mentioned above is very likely the cause of your troubles.
I had this problem and it turned out that the shell wasn't set correctly in the /etc/passwd file.
To solve it, I opened the file with
sudo vipw
and added /bin/bash to the my account's data there.
Try to:
export SHELL=/bin/sh
before running gdb
I had met same problem. When my
SHELL=/usr/local/bin/tcsh
but I have only the file .cshrc, gdb reports the same error.
When I change SHELL:
setenv SHELL /bin/csh
Then everything goes fine.
As normal, when I executing backtrace command in gdb, it always shows the full path for every frame in file section like:
function name() at /home/username/development/path/to/file/source.cpp:20
I'd like to remove the path prefix and only show:
function name() at path/to/file/source.cpp:20
What is the GDB setting command that I can use?
I think the answer may be to use relative rather than absolute paths at compile time, so the desired strings get into your binary.