Tag Info

New answers tagged

7

They are just a convention as much as any other convention. EDITOR and PAGER are mentioned in the standards as belonging to variables you'd be unwise to conflict with since they are widely used. See Chapter 8, Section 1: It is unwise to conflict with certain variables that are frequently exported by widely used command interpreters and applications: ...


5

It is convention going as far back as I can remember, like 30+ years. The BSD 4.2 Manual page for mail of 1 April 1983 mentions EDITOR, SHELL, and VISUAL. PAGER isn't mentioned in BSD 4.2's verion of "man": If the standard output is a teletype, or if the flag - is given, man pipes its output through cat(1) But it is in in 4.3 Reno circa 1990. ...


0

http://docs.oracle.com/cd/E23824_01/html/E24456/userenv-1.html Looks like we don't really need MANPATH at all, simply adjust PATH and the man commands would do the rest.


2

There is no central authority who assigns an official meaning to environment variables before applications can use them. POSIX defines the meaning of some variables (PATH, TERM, …) and lists several more in a non-normative way as being in common use, all of them in uppercase. http_proxy and friends isn't one of them. Unlike basically all conventional ...


0

The convention is to use all capps environment variables when exporting them, so that when you are writing shell scripts you can use lowercase variable names without worrying about name collisions with other programs. Of course this is a convention only, there is no technical restriction on limiting the names of environment variables so the lowercase version ...


-1

Both http_proxy and HTTP_PROXY should work on RHEL and ubuntu based systems.


0

By setting shell=/usr/bin/zsh\ -l in .vimrc solved my problem Note: I'm using: linux mint 17.1


1

Is there a smart/secure/easy way to make these changes temporary for specific process? Environment variables such as $JAVA_HOME are inherited, not global to the system. So if you set one a specific way, it applies only to that process, and if exported, any process it spawns. The process here would be a shell instance; you can either do this on the ...


0

It is possible to do that using the env command, however you have to use a little work around and call sh, see the following code snippets: # env var=bla echo $var > # env var=bla sh -c 'echo $var' > bla # echo $var > You can find more information using on info coreutils 'env invocation' Unfortunatelly I can't give you any further explanations ...


2

Running gsettings reset-recursively org.gnome.system.proxy fixed the problem. There are two ways to define proxy settings: Manually set the http_proxy environment variable in /etc/environment or your bash profile. Define it in gnome system settings. I had not set the environment variable manually which is why recursive grep didn't find anything. ...


0

What you most likely want to do is export the variables you are interested in. The following will make the variable available to the current shell and any sub-processes it creates: export PYTHONPATH=$PYTHONPATH:/Users/James/project Here a process that uses PYTHONPATH will first search the existing path for its target and if not found, try the ...


1

On linux, the reading of /etc/environment is usually done by the pam_env.so module during login. This module may not be installed on a minimal system, or may be configured not to read the /etc file, or it may not be configured in /etc/pam.d/* to be called during the login process. See man pam_env pam.


0

There is no obligation coded into most shells to load /etc/environment. Which exact files the shell looks for and what order it attempts to load them depends on the actual shell you use, but in general only /etc/shellnamerc and ~/.shellnamerc are ones you can absolutely count on being read, usually in that order. Consult your preferred shell's manpage for ...


1

As folks already noted, put the /bin only in JSX_HOME or PATH, not both. Also, in .bashrc, it appears you have a tilde at the beginning of JSX_HOME. Since there wasn't one on the install path you listed, try removing that.


0

Try echo $ENV_VAR | base64 --decode | json_reformat. If this is a 6.x or higher Centos version, you should have it


1

cat file.json | json_pp #perl utility cat file.json | jq . The latter (https://stedolan.github.io/jq/) packs much more than just pretty-printing abilities.


0

OK, that output is JSON. So parse as JSON: #!/usr/bin/perl; use strict; use warnings; use JSON; local $/; print to_json ( decode_json ( <> ), {pretty => 1 }); Will print your thing as: { "something" : [ { "host" : "something.internal", "scheme" : "solr", "ip" : "123.4.567.89", "path" : "something", ...


1

I would pipe that into yaml (which is part of ruamel.yaml of which I am the author): echo $ENV_VAR | base64 --decode | yaml from-json - will give you this (based on your example output): second_database: - username: user password: '' ip: 123.4.567.89 host: second_database.internal path: main query: is_master: true scheme: mysql port: ...


1

Usually this means that rvm is not setup correctly. The usual mistake is that you didn't modify your bashrc correctly (or simular) or you did not reload your terminal. You should not set GEM_HOME or GEM_PATH manually when using rvm. You can try ´source ~/.rvm/scripts/rvm´ and see if that works. It could also be that you have not built a gemset yet. Do ...


1

Sounds like you want the command export for setting environment variables: export PATH=$PATH':/path/to/add' export GEM_HOME=$HOME/.gem export GEM_PATH=$HOME/.gem That will only take effect for the current session, though. To make them more permanent, add those lines to your ~/.bashrc.


0

You can pass environments using the 'env' argument right before you invoke your app. I've done this for a single environment, though I'm not sure how one would provide multiple envariables exec chpst -u www-data:www-data env LOGNAME='www-data' /var/www/myapp/myapp


4

That's because unset is a shell builtin and not an external command. This means that xargs can't use it since that only runs commands that are in your $PATH. You'd get the same problem if you tried with cd: $ ls -l total 4 drwxr-xr-x 2 terdon terdon 4096 Jun 16 02:02 foo $ echo foo | xargs cd xargs: cd: No such file or directory One way around this is to ...


1

When you log in via a normal method (on the console, over SSH, etc.), the program handling the login sets a few environment variables, including HOME. If you get access to a shell not via logging in, but by exploiting a vulnerability in a program, you get that program's environment, which often but not always includes HOME. In bash, for some reason, the cd ...


6

export makes a variable something that will be included in child process environments. It does not affect other already existing environments. In general there isn't a way to set a variable in one terminal and have it automatically appear in another terminal, the environment is established for each process on its own. Adding it to your .profile makes it ...


4

zsh prompt expansion lets you do that prompt without having to do any calculation: PS1='%$COLUMNS>╡>%F{cyan}╔╡%F{red}[%n]%F{cyan}:%F{yellow}[%m]%F{cyan}➾%F{green}[%~]%F{default}$PS1_GIT%F{cyan}${(l:COLUMNS::═:):-}%<< ╚═╡%F{default}' Explained: %$COLUMNS>╡>: right-truncate to $COLUMNS (a variable set dynamically by zsh to the width of ...


3

You're using the wrong variable name. The $HOSTNAME environment variable is often set by the host system's init routines, but not always. In the context of a ZSH profile you should use the environment variable $HOST which is explicitly set by the shell. From man zshall: PARAMETERS SET BY THE SHELL     […] ...


1

You should just set HOSTNAME=$(hostname) in your ~/.zshrc Or as Caleb pointed out there is a variable HOST set, so to keep your prompt portable you could also do: HOSTNAME=$HOST


2

Insted of .bashrc put the setting line to /etc/profile. This file is loaded on every user login just like .bashrc is for a specific user. The bonus is this works for other shells and sessions as well.


2

In zsh, Command Substitution result was performed word splitting if was not enclosed in double quotes. So if your command substitution result contain any whitespace, tab, or newline, the export command will be broken into parts: $ export a=$(echo 1 -2) export: not valid in this context: -2 You need to double quote command substitution to make it work, or ...


1

I think I got it, for POSIX compliance I need double quotes here. The following fixed it. export CONDA_ENV_PATH="$(get_dirname "$_THIS_DIR")" The following excellent article may be helpful: When is double-quoting necessary?


0

Another way to do this: rm -r "${somevar:-/tmp/or_this_if_somevar_is_empty}"/* There are many variable substitutions, the one above is when "somevar" is empty (and in that case it attempts to delete /tmp/or_this_if_somevar_is_empty/* )


15

[ -z "$PROJECT_HOME" ] || rm -r "$PROJECT_HOME"/* This will also catch the case where PROJECT_HOME is set but doesn't contain anything. Example: 1) This will delete pretty much everything you can delete on your system (barring dotfiles inside / (there aren't usually any)): set -u PROJECT_HOME= rm -r "$PROJECT_HOME"/* 2) This won't do anything: ...


21

In POSIX shell, you can use set -u: #!/bin/sh set -u : "${UNSET_VAR}" or using Parameter Expansion: : "${UNSET_VAR?Unset variable}" In your case, you should use :? instead of ? to also fail on set but empty variables: rm -rf -- "${PROJECT_HOME:?PROJECT_HOME empty or unset}"/*



Top 50 recent answers are included