Rails app does not read env variables in .bashrc - ruby-on-rails

I have saved some ENV's in ~/.bashrc, I close and reopened the file and they are there for sure.
.bashrc:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
. /etc/apache2/envvars
# If not running interactively, don't do anything else
[ -z "$PS1" ] && return
# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
. /etc/bash_completion
fi
PS1='\[\033[01;32m\]${C9_USER}\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 " (%s)") $ '
# If this is an xterm set the title to user#host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u#\h: \w\a\]$PS1"
;;
*)
;;
esac
export rvm_silence_path_mismatch_check_flag=1
export TWILIO_SID="AXXXXX81b7eb5aXXXXeXXX6c9bfecX6X"
export TWILIO_TOKEN="XXX87XXXXXXe650ff2XXXXfXXXXX8X2"
export TWILIO_PHONE_NUMBER="+147043XXXX"
Yet when I tell my rails app to use them, for example use ENV["TWILIO_SID"] in my controller, it does not know them. I tried echoing them out in bash, it's just an empty line, in HTML, also empty line.
I am using c9 cloud IDE, and there is an option to manually enter ENV into the Rails shell, and when I do that, everything works fine. but my assignment asks for bashrc file... why are neither bash nor rails terminal reading my .bashrc? any help?
PS: the overall goal is to just set a UNIX env variable in my Rails app. I cannot use figaro.
PS2: Here is the code in controller where I'm using the variables. When I hard code them, everything works fine, so I know there is something going on with the env variables.
require 'twilio-ruby'
def index
end
class TexterController < ApplicationController
def index
end
def text
#number = params[:number]
#message = params[:message]
twilio_sid = ENV["TWILIO_SID"]
twilio_token = ENV["TWILIO_TOKEN"]
twilio_phone_number = ENV["TWILIO_PHONE_NUMBER"]
#client = Twilio::REST::Client.new(twilio_sid, twilio_token)
#message = #client.messages.create(
to: #number,
from: twilio_phone_number,
body: #message
)
render "pages/text.html.erb"
end
end

And here is the reasons why:
To change the environmental variable "permanently" you'll need to consider at least these situations:
Login/Non-login shell
Interactive/Non-interactive shell
Bash as login shell will load /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profile in the order
Bash as non-login interactive shell will load ~/.bashrc
Bash as non-login non-interactive shell will load the configuration specified in environment variable $BASH_ENV
Source: how to permanently set environmental variables

Found it.
Turns out for some reason, even when I source .bashrc, the env variables are not read, but when I added them to .profile they are read and everything works fine.
Even tried adding them to .bashrc and then source ~/.bashrc to .profile, but still wouldn't work.

Related

Adaptive Ruby version when opening a terminal

This question is the opposite of this one (also asked here, here and here)
I have two versions of ruby installed
ubuntu:~/environment $ rvm list
ruby-2.6.6 [ x86_64 ]
=* ruby-3.0.2 [ x86_64 ]
and every time I open a terminal window, ruby-3.0.2 (the default) is set. The problem is for a couple of my older projects I have to use ruby-2.6.6, so every time I have to switch with
rvm use 2.6.6
Is there a way to automatically select ruby 2.6.6 when I open the terminal window of the specific projects? I have tried to override the default rvm version with the .ruby-version file (as suggested here) but it does not do the trick.
EDIT File /home/ubuntu/.rvm/scripts/cd contains the following
#!/usr/bin/env bash
# Source a .rvmrc file in a directory after changing to it, if it exists. To
# disable this feature, set rvm_project_rvmrc=0 in /etc/rvmrc or $HOME/.rvmrc
case "${rvm_project_rvmrc:-1}" in
1|cd)
# cloned from git#github.com:mpapis/bash_zsh_support.git
source "$rvm_scripts_path/extras/bash_zsh_support/chpwd/function.sh"
# not using default loading to support older Zsh
[[ -n "${ZSH_VERSION:-}" ]] &&
__rvm_version_compare "$ZSH_VERSION" -gt 4.3.4 ||
{
function cd() { __zsh_like_cd cd "$#" ; }
function popd() { __zsh_like_cd popd "$#" ; }
function pushd() { __zsh_like_cd pushd "$#" ; }
}
__rvm_after_cd()
{
\typeset rvm_hook
rvm_hook="after_cd"
if [[ -n "${rvm_scripts_path:-}" || -n "${rvm_path:-}" ]]
then source "${rvm_scripts_path:-$rvm_path/scripts}/hook"
fi
}
__rvm_cd_functions_set()
{
__rvm_do_with_env_before
if [[ -n "${rvm_current_rvmrc:-""}" && "$OLDPWD" == "$PWD" ]]
then rvm_current_rvmrc=""
fi
__rvm_project_rvmrc >&2 || true
__rvm_after_cd || true
__rvm_do_with_env_after
return 0
}
[[ " ${chpwd_functions[*]} " == *" __rvm_cd_functions_set "* ]] ||
chpwd_functions=( "${chpwd_functions[#]}" __rvm_cd_functions_set )
# This functionality is opt-in by setting rvm_cd_complete_flag=1 in ~/.rvmrc
# Generic bash cd completion seems to work great for most, so this is only
# for those that have some issues with that.
if (( ${rvm_cd_complete_flag:-0} == 1 ))
then
# If $CDPATH is set, bash should tab-complete based on directories in those paths,
# but with the cd function above, the built-in tab-complete ignores $CDPATH. This
# function returns that functionality.
_rvm_cd_complete ()
{
\typeset directory current matches item index sep
sep="${IFS}"
export IFS
IFS=$'\n'
COMPREPLY=()
current="${COMP_WORDS[COMP_CWORD]}"
if [[ -n "$CDPATH" && ${current:0:1} != "/" ]] ; then
index=0
# The change to IFS above means that the \command \tr below should replace ':'
# with a newline rather than a space. A space would be ignored, breaking
# TAB completion based on CDPATH again
for directory in $(printf "%b" "$CDPATH" | \command \tr -s ':' '\n') ; do
for item in $( compgen -d "$directory/$current" ) ; do
COMPREPLY[index++]=${item#$directory/}
done
done
else
COMPREPLY=( $(compgen -d ${current}) )
fi
IFS="${sep}";
}
complete -o bashdefault -o default -o filenames -o dirnames -o nospace -F _rvm_cd_complete cd
fi
;;
2|prompt)
if
[[ -n "${ZSH_VERSION:-}" ]]
then
precmd_functions+=(__rvm_do_with_env_before __rvm_project_rvmrc __rvm_do_with_env_after)
else
PROMPT_COMMAND="${PROMPT_COMMAND%% }"
PROMPT_COMMAND="${PROMPT_COMMAND%%;}"
PROMPT_COMMAND="${PROMPT_COMMAND:-}${PROMPT_COMMAND:+; }__rvm_do_with_env_before; __rvm_project_rvmrc; __rvm_do_with_env_after"
fi
;;
esac
You are probably using RVM as a shell script, and not as a shell function.
You can check like this in a typical shell (bash, zsh, ...) : execute: type rvm
If it displays rvm is /home/ying/.rvm/bin/rvm : you are using as a script (found in $PATH)
If it displays rvm is a function : you are using as a function (much better).
Check out: https://rvm.io/rvm/basics#post-install-configuration
If you are using as a script, and want to use as a function: you need to "source" the rvm function, it is located in <rvm main folder>/scripts/rvm, for instance if installed in $HOME:
source $HOME/.rvm/scripts/rvm
source /usr/local/rvm/scripts/rvm
Typically, at RVM installation time, it add the following line in the equivalent of .profile (depending on shell and if its global or user):
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
RVM changes automatically the version as described here:
https://rvm.io/workflow/projects
For detection of .ruby-version, the following is required:
RVM must be a recent version that supports the feature
RVM must be loaded in the shell (typically by .profile, or equivalent) so that is is executed as a function
the shell must be compatible with this callback feature (bash and zsh are)
Here is what happens:
When you load rvm as a function, it registers callback in the shell
when you cd into the project, RVM callbacks (in shell) detect the file .ruby-version (or others) and automatically do the equivalent of rvm use.
For instance, I use zsh (on osx) which has preexec and precmd callbacks
and it detect the ruby version file and applies when I cd into it or a sub folder.
It works with bash too.
If you are curious or want to see why it does not work for you look at the file <rvm main dir>/scripts/cd
typically the shell variable chpwd_functions is set to __rvm_cd_functions_set
which is the function called after a cd by rvm

How to pass environment variables to docker container app user [duplicate]

When I use any command with sudo the environment variables are not there. For example after setting HTTP_PROXY the command wget works fine without sudo. However if I type sudo wget it says it can't bypass the proxy setting.
First you need to export HTTP_PROXY. Second, you need to read man sudo, and look at the -E flag. This works:
$ export HTTP_PROXY=foof
$ sudo -E bash -c 'echo $HTTP_PROXY'
Here is the quote from the man page:
-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their
existing environment variables. The security policy may return an error
if the user does not have permission to preserve the environment.
The trick is to add environment variables to sudoers file via sudo visudo command and add these lines:
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"
taken from ArchLinux wiki.
For Ubuntu 14, you need to specify in separate lines as it returns the errors for multi-variable lines:
Defaults env_keep += "http_proxy"
Defaults env_keep += "https_proxy"
Defaults env_keep += "HTTP_PROXY"
Defaults env_keep += "HTTPS_PROXY"
For individual variables you want to make available on a one off basis you can make it part of the command.
sudo http_proxy=$http_proxy wget "http://stackoverflow.com"
You can also combine the two env_keep statements in Ahmed Aswani's answer into a single statement like this:
Defaults env_keep += "http_proxy https_proxy"
You should also consider specifying env_keep for only a single command like this:
Defaults!/bin/[your_command] env_keep += "http_proxy https_proxy"
A simple wrapper function (or in-line for loop)
I came up with a unique solution because:
sudo -E "$#" was leaking variables that was causing problems for my command
sudo VAR1="$VAR1" ... VAR42="$VAR42" "$#" was long and ugly in my case
demo.sh
#!/bin/bash
function sudo_exports(){
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) "$#"
}
# create a test script to call as sudo
echo 'echo Forty-Two is $VAR42' > sudo_test.sh
chmod +x sudo_test.sh
export VAR42="The Answer to the Ultimate Question of Life, The Universe, and Everything."
export _EXPORTS="_EXPORTS VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9 VAR10 VAR11 VAR12 VAR13 VAR14 VAR15 VAR16 VAR17 VAR18 VAR19 VAR20 VAR21 VAR22 VAR23 VAR24 VAR25 VAR26 VAR27 VAR28 VAR29 VAR30 VAR31 VAR32 VAR33 VAR34 VAR35 VAR36 VAR37 VAR38 VAR39 VAR40 VAR41 VAR42"
# clean function style
sudo_exports ./sudo_test.sh
# or just use the content of the function
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) ./sudo_test.sh
Result
$ ./demo.sh
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
How?
This is made possible by a feature of the bash builtin printf. The %q produces a shell quoted string. Unlike the parameter expansion in bash 4.4, this works in bash versions < 4.0
Add code snippets to /etc/sudoers.d
Don't know if this is available in all distros, but in Debian-based distros, there is a line at or near the tail of the /etc/sudoers file that includes the folder /etc/sudoers.d. Herein, one may add code "snippets" that modify sudo's configuration. Specifically, they allow control over all environment variables used in sudo.
As with /etc/sudoers, these "code snippets" should be edited using visudo. You can start by reading the README file, which is also a handy place for keeping any notes you care to make:
$ sudo visudo -f /etc/sudoers.d/README
# files for your snippets may be created/edited like so:
$ sudo visudo -f /etc/sudoers.d/20_mysnippets
Read the "Command Environment" section of 'man 5 sudoers'
Perhaps the most informative documentation on environment configuration in sudo is found in the Command environment section of man 5 sudoers. Here, we learn that a sudoers environment variables that are blocked by default may be "whitelisted" using the env_check or env_keep options; e.g.
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
Defaults env_keep += "ftp_proxy FTP_PROXY"
And so, in the OP's case, we may "pass" the sudoer's environment variables as follows:
$ sudo visudo -f /etc/sudoers.d/10_myenvwlist
# opens the default editor for entry of the following lines:
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
# and any others deemed useful/necessary
# Save the file, close the editor, and you are done!
Get your bearings from '# sudo -V'
The OP presumably discovered the missing environment variable in sudo by trial-and-error. However, it is possible to be proactive: A listing of all environment variables, and their allowed or denied status is available (and unique to each host) from the root prompt as follows:
# sudo -V
...
Environment variables to check for safety:
...
Environment variables to remove:
...
Environment variables to preserve:
...
Note that once an environment variable is "whitelisted" as above, it will appear in subsequent listings of sudo -V under the "preserve" listing.
If you have the need to keep the environment variables in a script you can put your command in a here document like this. Especially if you have lots of variables to set things look tidy this way.
# prepare a script e.g. for running maven
runmaven=/tmp/runmaven$$
# create the script with a here document
cat << EOF > $runmaven
#!/bin/bash
# run the maven clean with environment variables set
export ANT_HOME=/usr/share/ant
export MAKEFLAGS=-j4
mvn clean install
EOF
# make the script executable
chmod +x $runmaven
# run it
sudo $runmaven
# remove it or comment out to keep
rm $runmaven

How can I avoid certain lines from .bashrc and .inputrc from being loaded in tmux?

I have these lines in my .inputrc:
"(": "\C-v()\ei"
"[": "\C-v[]\ei"
"{": "\C-v{}\ei"
"\"": "\C-v\"\C-v\"\ei"
"\'": "\C-v\'\C-v\'\ei"
This autocloses quotes and brackets in a terminal. But it causes an inconvenience in a tmux session: when I send text containing quotes to frome one pane (vim) to another pane (bash / python / R etc), every quote is turned into two, very annoying.
Is it possible to disable these lines in (and only in) tmux?
tmux sets the TMUX environment variable, so in .bashrc (or .profile or whatever):
if [ '' = "$TMUX" ] ; then
echo not in TMUX
else
echo in TMUX
fi
You can set INPUTRC to override the default .inputrc location, so you could have a tmux one and a non-tmux one, and export a suitable INPUTRC value in .bashrc depending on TMUX. You could even concoct a suitable .inputrc (e.g. in /tmp) for that session based on a "common" file and a "non-tmux session" file.
Unfortunately tmux exports TMUX, and so subshells started from a tmux session will have TMUX set regardless. Not found a way round that yet.
I ended up doing this in ~/.bashrc:
if [[ '' = "$TMUX" ]]
then
set -o vi
bind -m vi-insert '"(" "\C-v()\ei"'
bind -m vi-insert '"[" "\C-v[]\ei"'
bind -m vi-insert '"{" "\C-v{}\ei"'
bind -m vi-insert '"\"" "\C-v\"\C-v\"\ei"'
bind -m vi-insert '"\047" "\C-v\047\C-v\047\ei"'
else
echo Welcome to Tmux!
fi
UPDATE
Adopting user3392484 's suggestion, I found this much better:
if [[ '' = "$TMUX" ]]
then
export INPUTRC=~/.inputrc
else
export INPUTRC=~/.tmux.inputrc
echo Welcome to Tmux!
fi

Installing more than one version of Erlang/OTP on a machine

Is this possible to have different versions of Erlang/OTP installed simultaneously on the same platform?
I use Kerl to install Erlang on my machines. Quite easy to use, and allows to have several Erlang systems installed on same machine. You can then easily choose the one you want to use.
It is no only possible, but also very frequent. On my machine I have one version that I installed for development (R13B03) it is the default version when I launch erl.
A second copy of the same version associated with nitrogen. this copy is used when I start my nitrogen website. The version will not change when I will use the R16B.. for development
A partial older version which came with the installation of Wings3D.
Yes, I usually install different versions in my home directory. I build them from source:
./configure --prefix=$HOME/r15b01
make && make install
Then I can choose a version to use with PATH=$HOME/r15b01/bin:$PATH, and compile and run things as usual.
These days I use asdf for this. Install asdf and add the relevant line to your .bashrc, and then run:
asdf plugin add erlang
asdf install erlang 22.3.3
asdf install erlang 23.0.2
Then you can set one of the Erlang versions you just built as the default version:
asdf global erlang 23.0.2
Or you can set it to be used in the current directory and its subdirectories - this will create a .tool-versions file in the current directory:
asdf local erlang 22.3.3
On a Mac, Macport helps switching, even between versions it covers and newer ones.
E.g. with Erlang 17 installed directly from Erlang Solutions, you could switch back to RB1603 (open a new terminal window afterwards):
sudo port activate erlang #R16B03-1_0+hipe+ssl
Switch back to Erlang 17 by _de_activating the Macports install (and open a new terminal window afterwards):
sudo port deactivate erlang #R16B03-1_0+hipe+ssl
List all versions you have installed with:
port installed erlang
Using the Nix package manager there is no need to globally install interpreters (especially because sometimes multiple versions are needed), and nix-shell will open up a sub-shell with the Erlang executable available in the path.
1. Getting only the Erlang (no shell.nix)
For the current version in the active channel:
nix-shell -p erlang
For other versions not in the current channel, a specific channel can be given:
nix-shell -I nixpkgs=channel:nixos-unstable -p erlangR22
Or add path to the Nix expression in your NixOS/nixpkgs clone:
$ nix-shell -I nixpkgs=~/clones/nixpkgs -p erlangR23
2. More elaborate project setup configurations: use a shell.nix file
A complex development environment can be spun up, and calling nix-shell shell.nix will take care of all - even automatically when entering a directory if set up with direnv(archived).
2.1 Examples
Erlang
This will drop you in a shell with erl and rebar3 available, along with the other programs specified in buildInputs.
{ pkgs ? import ~/clones/nixpkgs {} }:
pkgs.mkShell {
buildInputs = with pkgs; [
beam.packages.erlangR22.erlang
beam.packages.erlangR22.rebar3
curl
ffmpeg
git
google-cloud-sdk
jq
];
# Where would be the best place for this?
shellHook = ''
export ERL_AFLAGS="-kernel shell_history enabled"
'';
Elixir/Phoenix web project
This (archived) will set up an environment for an Elixir/Phoenix web app complete with a spun up PostgreSQL dev instance:
####################################################################
# Importing a cloned Nixpkgs repo (from my home directory), because
# the latest channels don't have Elixir 1.9.
# See https://nixos.org/nix/manual/#idm140737317975776 for the meaning
# of `<nixpkgs>` and `~` in Nix expressions (towards the end of that
# section).
####################################################################
{ pkgs ? import ~/clones/nixpkgs {} }:
pkgs.mkShell {
buildInputs = with pkgs; [
beam.packages.erlangR22.elixir_1_9
postgresql_11
nodejs-12_x
git
inotify-tools
];
shellHook = ''
####################################################################
# Create a diretory for the generated artifacts
####################################################################
mkdir .nix-shell
export NIX_SHELL_DIR=$PWD/.nix-shell
####################################################################
# Put the PostgreSQL databases in the project diretory.
####################################################################
export PGDATA=$NIX_SHELL_DIR/db
####################################################################
# Put any Mix-related data in the project directory
####################################################################
export MIX_HOME="$NIX_SHELL_DIR/.mix"
export MIX_ARCHIVES="$MIX_HOME/archives"
####################################################################
# Clean up after exiting the Nix shell using `trap`.
# ------------------------------------------------------------------
# Idea taken from
# https://unix.stackexchange.com/questions/464106/killing-background-processes-started-in-nix-shell
# and the answer provides a way more sophisticated solution.
#
# The main syntax is `trap ARG SIGNAL` where ARG are the commands to
# be executed when SIGNAL crops up. See `trap --help` for more.
####################################################################
trap \
"
######################################################
# Stop PostgreSQL
######################################################
pg_ctl -D $PGDATA stop
######################################################
# Delete `.nix-shell` directory
# ----------------------------------
# The first step is going back to the project root,
# otherwise `.nix-shell` won't get deleted. At least
# it didn't for me when exiting in a subdirectory.
######################################################
cd $PWD
rm -rf $NIX_SHELL_DIR
" \
EXIT
####################################################################
# If database is not initialized (i.e., $PGDATA directory does not
# exist), then set it up. Seems superfulous given the cleanup step
# above, but handy when one gets to force reboot the iron.
####################################################################
if ! test -d $PGDATA
then
######################################################
# Init PostgreSQL
######################################################
pg_ctl initdb -D $PGDATA
######################################################
# PORT ALREADY IN USE
######################################################
# If another `nix-shell` is running with a PostgreSQL
# instance, the logs will show complaints that the
# default port 5432 is already in use. Edit the line
# below with a different port number, uncomment it,
# and try again.
######################################################
# sed -i "s|^#port.*$|port = 5433|" $PGDATA/postgresql.conf
fi
####################################################################
# Start PostgreSQL
# ==================================================================
# Setting all necessary configuration options via `pg_ctl` (which
# is basically a wrapper around `postgres`) instead of editing
# `postgresql.conf` directly with `sed`. See docs:
#
# + https://www.postgresql.org/docs/current/app-pg-ctl.html
# + https://www.postgresql.org/docs/current/app-postgres.html
#
# See more on the caveats at
# https://discourse.nixos.org/t/how-to-configure-postgresql-declaratively-nixos-and-non-nixos/4063/1
# but recapping out of paranoia:
#
# > use `SHOW` commands to check the options because `postgres -C`
# > "_returns values from postgresql.conf_" (which is not changed by
# > supplying the configuration options on the command line) and
# > "_it does not reflect parameters supplied when the cluster was
# > started._"
#
# OPTION SUMMARY
# --------------------------------------------------------------------
#
# + `unix_socket_directories`
#
# > PostgreSQL will attempt to create a pidfile in
# > `/run/postgresql` by default, but it will fail as it
# > doesn't exist. By changing the configuration option
# > below, it will get created in $PGDATA.
#
# + `listen_addresses`
#
# > In tandem with edits in `pg_hba.conf` (see
# > `HOST_COMMON` below), it configures PostgreSQL to
# > allow remote connections (otherwise only `localhost`
# > will get authenticated and the rest of the traffic
# > discarded).
# >
# > NOTE: the edit to `pga_hba.conf` needs to come
# > **before** `pg_ctl start` (or the service
# > needs to be restarted otherwise), because then
# > the changes are not being reloaded.
# >
# > More info on setting up and troubleshooting remote
# > PosgreSQL connections (these are all mirrors of the
# > same text; again, paranoia):
# >
# > + https://stackoverflow.com/questions/24504680/connect-to-postgres-server-on-google-compute-engine
# > + https://stackoverflow.com/questions/47794979/connecting-to-postgres-server-on-google-compute-engine
# > + https://medium.com/scientific-breakthrough-of-the-afternoon/configure-postgresql-to-allow-remote-connections-af5a1a392a38
# > + https://gist.github.com/toraritte/f8c7fe001365c50294adfe8509080201#file-configure-postgres-to-allow-remote-connection-md
HOST_COMMON="host\s\+all\s\+all"
sed -i "s|^$HOST_COMMON.*127.*$|host all all 0.0.0.0/0 trust|" $PGDATA/pg_hba.conf
sed -i "s|^$HOST_COMMON.*::1.*$|host all all ::/0 trust|" $PGDATA/pg_hba.conf
# + `log*`
#
# > Setting up basic logging, to see remote connections
# > for example.
# >
# > See the docs for more:
# > https://www.postgresql.org/docs/current/runtime-config-logging.html
pg_ctl \
-D $PGDATA \
-l $PGDATA/postgres.log \
-o "-c unix_socket_directories='$PGDATA'" \
-o "-c listen_addresses='*'" \
-o "-c log_destination='stderr'" \
-o "-c logging_collector=on" \
-o "-c log_directory='log'" \
-o "-c log_filename='postgresql-%Y-%m-%d_%H%M%S.log'" \
-o "-c log_min_messages=info" \
-o "-c log_min_error_statement=info" \
-o "-c log_connections=on" \
start
####################################################################
# Install Node.js dependencies if not done yet.
####################################################################
if test -d "$PWD/assets/" && ! test -d "$PWD/assets/node_modules/"
then
(cd assets && npm install)
fi
####################################################################
# If $MIX_HOME doesn't exist, set it up.
####################################################################
if ! test -d $MIX_HOME
then
######################################################
# ... but first, test whether there is a `_backup`
# directory. Had issues with installing Hex on NixOS,
# and Hex and Phoenix can be copied from there, just
# in case.
######################################################
if test -d "$PWD/_backup"
then
cp -r _backup/.mix .nix-shell/
else
######################################################
# Install Hex and Phoenix via the network
######################################################
yes | mix local.hex
yes | mix archive.install hex phx_new
fi
fi
if test -f "mix.exs"
then
# These are not in the `if` section above, because of
# the `hex` install glitch, it could be that there is
# already a `$MIX_HOME` folder. See 2019-08-05_0553
mix deps.get
######################################################
# `ecto.setup` is defined in `mix.exs` by default when
# Phoenix project is generated via `mix phx.new`.
# It does `ecto.create`, `ecto.migrate`, and run
# `priv/seeds`.
######################################################
mix ecto.setup
fi
'';
####################################################################
# Without this, almost everything fails with locale issues when
# using `nix-shell --pure` (at least on NixOS).
# See
# + https://github.com/NixOS/nix/issues/318#issuecomment-52986702
# + http://lists.linuxfromscratch.org/pipermail/lfs-support/2004-June/023900.html
####################################################################
LOCALE_ARCHIVE = if pkgs.stdenv.isLinux then "${pkgs.glibcLocales}/lib/locale/locale-archive" else "";
}
How to find packages with attributes path on the console
$ nix-env -qaP 'erlang*'
# ...
nixos.erlangR20 erlang-20.3.8.9
nixos.erlangR21 erlang-21.3.8.3
nixos.erlang erlang-22.1.7
# ...
$ nix-env -f ~/clones/nixpkgs/ -qaP 'erlang*'
# ...
nixos.erlangR20 erlang-20.3.8.9
nixos.erlangR21 erlang-21.3.8.3
nixos.erlang erlang-22.1.7
# ...
=== >>> erlangR23 erlang-23.0.2 <<<====
Consider using kerl. It allows you to work with several Erlang installations https://github.com/kerl/kerl

Show and execute

In this makefile
dirs = $(shell ls)
clean:
$(foreach dir,$(dirs),echo $(dir);)
The output is
$ make clean
echo bin; echo install.sh; echo Makefile; echo README.md; echo utils;
bin
install.sh
Makefile
README.md
utils
Why does it first show the command, then execute it?
How I can omit the first line?
Prepend the command with the # character. Example:
dirs = $(shell ls)
clean:
#$(foreach dir,$(dirs),echo $(dir);)
From the manual (5.2 Recipe Echoing, bold emphasis mine):
Normally make prints each line of the recipe before it is executed. We call this echoing because it gives the appearance that you are typing the lines yourself.
When a line starts with #, the echoing of that line is suppressed. The # is discarded before the line is passed to the shell. [...]
Alternatively:
The -s or --silent flag to make prevents all echoing, as if all recipes started with #.

Resources