New answers tagged

0

Another way to permanently add new path in LD_LIBRARY_PATH: Edit .conf file in /etc/ld.so.conf.d/. I have ever installed an application and its libraries couldn't be recognized by another application. Then I add the path, i.e /usr/local/hdf5/lib, to x86_64-linux-gnu.conf file. Just put in the next line. Save. Then run sudo ldconfig It worked. PS: OS ...


0

I would leave the history file alone and implement your recording of commands in the prompt_command handler instead. I would also make it write to a private log file then you don't have the conflicts with other usages of the history file or issues with other users accessing /root


3

$ declare -p > my_environment Later, inside barscript: . my_environment declare -p outputs environment variables in a form that can be executed by the shell, including quoting and escaping of variables as required. $ foobar='"some double-quoted text"' $ echo $foobar "some double-quoted text" $ declare -p foobar declare -- foobar="\"some ...


1

I'll try to answer all three parts of this question for you [Why is it] necessary to export LD_LIBRARY_PATH to ensure correct C# executable program behavior installation programs or scripts manage to find libc.so.6 in the subdirectory /usr/libx86_64-linux-gnu without requiring the customer specify an LD_LIBRARY_PATH Linked libraries are referenced ...


5

Are there any historical reasons for there being two commands instead of one? There was just history manner. Bill Joy wrote the first version of printenv command in 1979 for BSD. UNIX System III introduced env command in 1980. GNU followed UNIX System's env in 1986. BSD followed GNU/UNIX System's env in 1988. MINIX followed BSD's printenv in 1988. ...


2

No, it's not the same. env VAR1="blahblah" command_to_run command_options runs command_to_run with VAR1="blahblah" in its environment; the containing shell's environment isn't affected. VAR1="blahblah" export VAR1 command_to_run adds VAR1="blahblah" to the shell's environment and makes it available for all subsequent commands, including command_to_run. ...


0

Solution ... Exec=bash -i -c "/home/mozes/dev/sqldeveloper/sqldeveloper.sh" ... Explanation " -i If the -i option is present, the shell is interactive." Example XFCE launcher relying on environment variables from ~/.bashrc to provide info for SQLDeveloper so that it can find the TNS Listener aliases at tnsnames.ora ...


0

As far as I can tell, OS X uses code point collation order in UTF-8 locales, so it is an exception to some of the points mentioned in the answer by Stéphane Chazelas. This prints 26 in OS X and 310 in Ubuntu: export LC_ALL=en_US.UTF-8 printf %b $(printf '\\U%08x\\n' $(seq $((0x11)) $((0x10ffff))))|grep -a '[a-z]'|wc -l The code below prints nothing in ...


4

If your perl script produces no other output than the value of $circle, you can use command substitution to store that output in a variable. For example: circle=$(perl perlscript.pl) If the perl script produces other output as well (or not output at all), you'll have to either: extract only the value you want from the output using the usual text ...


-3

Just set an environment variable in perl and your shell will find it. In C you can check your path like this void getPath() { if (getenv("PATH") == NULL) { printf("'%s' is not set.\n", "PATH"); /* Default our path if it is not set. */ putenv("PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc"); } else if (getenv("PATH")) { ...


0

I have also experienced some issues with adding executables to my path. What worked for me is adding the line export PATH=$PATH:/home/ahuq/MappingServer/md5_program to the ~/.bash_profile. Unfortunately I don't know why but for met .bashrc didn't work but .bash_profile did.


10

The variable is available in the main script, since you used . (the dot builtin, also known as source in some shells). . ./vars executes vars in the context of the calling script. Your problem is that you're using printenv to check, but printenv only prints environment variables, not shell variables. Environment variables are managed by the operating system ...


10

Sourcing your script only sets shell variables, while printenv shows environment variables. You will have to export the variables for printenv to show them. You may have meant to use set instead, which will show shell variables. You could have made this script: #!/bin/sh export MYVAR=MYVAL echo "EXECUTED!!" (given that you are using bash, the export ...


7

If you really want to do it, there is a way. Add the following at the end of .bashrc in your home directory, and set PATHEXT to extension names with dots separated by :. (Changed to include the dots to match the Windows behavior.) Use it at your own risk. if declare -f command_not_found_handle >/dev/null; then eval ...


13

The simplest solution is to just not use extensions for your scripts. They are not necessary and only serve to identify the script's type to you, but not to the computer. While Windows uses extensions to identify the file type, *nix systems (with very few exceptions such as gzip) do not. Note that binaries have no .exe extension in *nix, they're just ...


6

short: no longer: shell scripts require a full filename, but you can define aliases for your commands to refer to them by various names. For example alias my-script=my-script.pl


1

Normally, screen accepts a command and arguments, so this might work: screen -m -S 'test' nohup ~/<script-to-be-run>.sh Because it is not expecting a variable assignment, and the variable might otherwise be reset, you would probably have to add env to set the variable: screen -m -S 'test' env DISPLAY=:0 nohup ~/<script-to-be-run>.sh'


1

/etc/environment is a configuration file for pam_env, not a file read by a shell. The syntax is somewhat similar, but it is not the same. In particular, you can't refer to existing variables: you've set your search path to contain $ORACLE_HOME/bin and $PATH, i.e. directories with a dollar sign in their name. To set variables for all users, you can edit ...


1

The assignments in /etc/environment should be exported. Otherwise their values are not used. If you use "." to source a file, then you would use this syntax: export ORACLE_HOME=/usr/lib/oracle/12.1/client64 export PATH=$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH=$ORACLE_HOME/lib But as noted, /etc/environment is not intended to be sourced (see for ...



Top 50 recent answers are included