how to go into the environment of "c". when using cygwin... please tell me the commands to go into the c environment....
If you want to cd to the C: drive then one way is:
$ cd /cygdrive/c
If you want to edit/compile/run/debug C programs, then it's:
$ emacs foo.c # edit
$ gcc -Wall foo.c -o foo # compile
$ ./foo # run
$ gdb ./foo # debug
Do you want to navigate to the C: drive when in the shell? If so, just do cd c:
Install cygwin from cygwin.org. Select development packages like gcc during the process. Open a cygwin shell and call gcc from the command line. Or whatever.
After reading the question, my first interpretation was that the question was about how to ensure that the C locale was set for the shell in Cygwin, rather than allowing the Windows locale to be inherited. Putting export LC_ALL=C or export LC_ALL=C.utf8 into your ~/.bashrc would force the C locale in all shell contexts. The command locale can be used to see your current locale before and after changing LC_ALL, which will help verify that the change is in effect. man bash (or your shell of choice) will provide more information on what is affected by the various locale-related environment variables.
Related
I am debugging some test failures (make test) for a Perl module on macOS. I discovered that the problem seems to be that the environment variable DYLD_LIBRARY_PATH is not forwarded to an external command run from within the Makefile. Here is a minimal example:
.PHONY: all
all:
#echo $$DYLD_LIBRARY_PATH
On Linux from the Bash shell, I can do (or rather replace DYLD_LIBRARY_PATH with LD_LIBRARY_PATH which is used for this purpose on Linux):
$ export DYLD_LIBRARY_PATH=bar
$ make
bar
However, if I run the same Makefile on macOS Catalina 10.15.5, the variable DYLD_LIBRARY_PATH is empty:
$ export DYLD_LIBRARY_PATH=bar
$ make
# [No output]
Any idea what is the reason for this difference?
first i used command : which gcc
If it shows location other than /usr/bin, then how to set the right path to compile the C program
It depends upon your $PATH. And that could be set to something starting with a directory containing some gcc command. Run echo $PATH to find out what is your current $PATH.
You could either type exactly /usr/bin/gcc, or add some alias to your interactive shell configuration (often ~/.bashrc which you might edit with great care), or change your PATH setting, or, assuming which gcc gives something like /home/zaid/bin/gcc (i.e. your $HOME/bin/gcc if $HOME/bin appears early in your $PATH), add a symbolic link ln -sv /usr/bin/gcc $HOME/bin/.
If you compile a program made of several translation units, you should use some build automation tool, probably GNU make. Try once make -p to understand the builtin rules known to your make and take advantage of these. Then, edit your Makefile, perhaps by adding near its beginning lines like
CC=/usr/bin/gcc
CFLAGS+= -Wall -g
The first line (with CC=) sets your C compiler in your Makefile. The second one (with CFLAGS+=) asks for all warnings (-Wall) & debug info (-g). Because you'll use the gdb debugger.
I've incurred a worrisome issue with my bash shell. I was editing my bash_profile and accidentally exported an incomplete command (export PATH=/usr/local/bin). After I had reloaded my terminal, nearly all of my bash commands fail to work properly. When I try to run any one of them, the errors state: command not found.
How do I fix this? Is there an alternate way to open or find my bash_profile?
I would appreciate any immediate input I can get on this issue. Thank you in advance.
You can execute commands if you can give the directory name. Almost all the basic Unix commands are under the /bin or /usr/bin directory. For example, /bin/mv.
Fortunately, builtin commands are still recognizable.
Move your .bash_profile and .bashrc file out of the way for now, and see what the system default is.
You can manually edit your PATH on the command line to:
$ PATH="/bin:/usr/bin"
$ cd
$ mv .bash_profile .bash_profile.bak
$ mv .bashrc .bashrc.bak
$ mv .profile .profile.bak
$ mv .bash_login .bash_login.bak
NOTE: Some of these mv command may fail simply because that particular file may not exist.
which will give you access to most of the basic Unix commands. Or you can specify the commands with their full directory names:
$ PATH="/bin:/usr/bin"
$ cd
$ /bin/mv .bash_profile .bash_profile.bak
$ /bin/mv .bashrc .bashrc.bak
$ /bin/mv .profile .profile.bak
$ /bin/mv .bash_login .bash_login.bak
Now, log in again and see what your default $PATH is set to. This is set by the /etc/profile. You might find that's just fine, and remove setting PATH in your startup script.
The standard for PATH is something like this:
/usr/share/bin or /usr/local/bin - These contain non-standard Unix/Linux commands. For example, if you install Maven on your system, the mvn command will usually be located in one of these directories (maybe as a symbolic link). This directory is a place where commands not found in the /bin and /usr/bin directory are stored. This directory is first, so you can replace the version which came with your system with more recent versions. For example, I might have VIM 6.4 installed, but I want to use version 7.3 instead.
/bin:/usr/bin - The standard directories where 99% of the Unix commands live.
$HOME/bin - These are executables you wrote -- either scripts or binaries. This is at the end of the PATH list because it makes sure that you don't accidentally execute the wrong version of the command. Imagine if some joker wrote a shell script called cp that executed /bin/rm instead and placed it in your $HOME/bin directory.
Other directories you'll see may include /sbin/ and /usr/sbin which are administrator commands (ping and ifconfig are sometimes in one of these directories.) /opt/bin/X11 (or wherever the X11 binaries are stored). Sometimes other commands will futz around with your PATH, for example Perlbrew.
#fedorqui's comment provides a quick fix.
The OP could also have used the following to quickly get to a shell with default values for $PATH:
To create a bash shell with a pristine default environment:
without running profile/initialization scripts
without inheriting any environment variables from the current shell
run:
/usr/bin/env -i bash --norc
Note:
Due to use of env's -i option, many environment variables that are normally set will NOT be set in the resulting shell , such as USER, HOME and LANG.
Similarly, the $PATH value you'll get is presumably one hard-coded into bash itself, but it should provide access to at least the standard utilities.
--norc suppresses loading of ~/.bashrc, which normally happens by default for interactive non-login bash shells (bash also supports the --noprofile option to suppress loading of /etc/profile and ~/.bash_profile, but it doesn't apply here, since the shell created is a non-login shell).
If env is in the current shell's $PATH, env -i bash --norc will do.
env is in /usr/bin/ on at least Linux and on FreeBSD/OSX, probably also on other platforms.
I have few path settings and alias in .bash_profile, and I am exporting those.
For eg:
alias gcc=/abc/def/......./myrtgcc
export gcc
And I want use myrtgcc to compile c programs either from terminal or from eclipse using the command "GCC", and I expect the system to use "myrtgcc" whenever I compile the programs using
myrtgcc somfile.c -o output
However this is not the case.
even after adding the above alias in .bash_profile, and restarting the system ( or use > source .bash_profile ) the changes are not reflected.
because, If I open the terminal and type
which gcc
I get /usr/bin/gcc and when eclipse uses "GCC" command it again invokes the same /usr/bin/gcc.
How do I make myrtgcc default across the system, for command gcc
Thank you.
Make a symbol link in /abc/def/xxx/myrtgcc
ln -s myrtgcc gcc
Put the path of myrtgcc in front of /usr/bin in your .bash_profile:
export PATH=/abc/def/xxx/myrtgcc:$PATH
I'm using python with setcap CAP_NET_RAW enabled. My python script imports a shared library which has $ORIGIN in its RPATH. Since my python is now a suid app, $ORIGIN is not evaluated and the library does not load correctly (this is due to a security leak found in glibc ).
Is there a way to tell the linker that my library path is secure and load the library anyway?
A few more notes:
I only need this feature in the development stage. I'm not looking for a production solution.
When working as root, everything works.
I do not want to work as root.
Thanks,
Dave
You can try one of these. Consider that <path-to-mylib> is the absolute pathname after solving the $ORIGIN rpath reference.
Re-run ldconfig after telling it where to find your library
$ echo "<path-to-mylib>" > /etc/ld.so.conf.d/my-new-library.conf
$ ldconfig -v
If running things as root is not an option, export LD_LIBRARY_PATH with the correct directory for every execution of the process
$ echo "export LD_LIBRARY_PATH=<path-to-mylib>" >> ~/.bashrc
$ export LD_LIBRARY_PATH=<path-to-mylib>
$ # then run your stuff...
Did you try sudo?
Instead of $ORIGIN, use fixed paths during development because they will work on setuid programs. Don't change your main build process, just use patchelf to set the rpath to what you need. You could make a shell script which does something like:
ln=`readelf -d |grep RPATH`
IFS=:
set -- $ln
newrpath=`echo $2 |sed 's/\$ORIGIN/\/devel\/myprog\/lib/'`
patchelf --set-rpath newrpath myprogram
Then your binary will no longer search $ORIGIN/../lib but /devel/myprog/lib/../lib