Code Monkey home page Code Monkey logo

autoenv's Introduction

Autoenv

Until recently, the default file name used by this plugin was .env, but now it is .in. This is done in order not to conflict with .env files from numerous projects.

Autoenv automatically sources (known/whitelisted) .in and .out files.

This plugin adds support for enter and leave events. By default .in files are used when entering a directory, and .out files when leaving a directory. And you can set variable CLICOLOR=1 for enabling colored output.

The environment variables $AUTOENV_IN_FILE & $AUTOENV_OUT_FILE can be used to override the default values for the file names of .in & .out respectively.

Example of use

  • If you are in the directory /home/user/dir1 and execute cd /var/www/myproject this plugin will source the following files if they exist
/home/user/dir1/.out
/home/user/.out
/home/.out
/var/.in
/var/www/.in
/var/www/myproject/.in
  • If you are in the directory / and execute cd /home/user/dir1 this plugin will source the following files if they exist
/home/.in
/home/user/.in
/home/user/dir1/.in
  • If you are in the directory /home/user/dir1 and execute cd / this plugin will source the following files if they exist
/home/user/dir1/.out
/home/user/.out
/home/.out

Examples of .in and .out files

Please, don't use pwd or $PWD, instead of this use $(dirname $0). Additionally, the path of the directory being entered or exited is passed as the first argument to both .in and .out scripts, should using a symlink be preferred.

For node.js developing:

.in

nvm use node
OLDPATH=$PATH
export PATH="$(dirname $0)/node_modules/.bin":$PATH

.out

nvm use system
export PATH=$OLDPATH

For projects with .env or/and .env.local

source $(dirname $0)/.env*

Prerequisites

This plugin depends on zsh-colors.

If you don't use zpm, install it manually and activate it before this plugin. If you use zpm you don’t need to do anything

Installation

Using zpm

Add zpm load zpm-zsh/autoenv into .zshrc

Using oh-my-zsh

Execute git clone https://github.com/zpm-zsh/autoenv ~/.oh-my-zsh/custom/plugins/autoenv. Add autoenv into plugins array in .zshrc

Using antigen

Add antigen bundle zpm-zsh/autoenv into .zshrc

Using zgen

Add zgen load zpm-zsh/autoenv into .zshrc

autoenv's People

Contributors

darcmattr avatar grigorii-horos avatar hellola avatar ithinuel avatar lowjoel avatar matthewflamm avatar nagasaki45 avatar rossmacarthur avatar sleepybag avatar tanvir002700 avatar unixorn avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

autoenv's Issues

It can`t work

plugins=(git,autoenv)
Plug horosgrisa/autoenv
antigen-bundle horosgrisa/autoenv

I write this in .zshrc but
.zshrc:46: command not found: Plug
.zshrc:47: command not found: antigen-bundle

Consider using .env.local before .env

For a lot of modern web projects each developer keeps their respective environment variables stored locally, usually in a form of .env.local or .env.*.local.

Each of these files is added to .gitignore to prevent committing stuff such as API keys or other environment variables specific to a project to the repository in a .env, as this file is often added to the filesystem before deployment process commences.

It would be great if the plugin considered sourcing .env.*.local or .env.local before .env to make sure creators of these project can benefit from this plugin while developing their software locally.

.env file loaded twice

Hello,

% cat ~/.env
echo "HOME .env"
% source ~/.zplugin/plugins/horosgrisa---autoenv/autoenv.plugin.zsh
HOME .env
HOME .env

$1 is passed to .env files

Bash function arguments are passed to the sourced .env and .out scripts. For example:

➜  ~  ls -a test_autoenv
.  ..  .env
➜  ~  cat test_autoenv/.env 
echo "$1"
➜  ~  cd test_autoenv 
/home/nagasaki45/test_autoenv/.env
➜  test_autoenv  

More info about this behavior can be found here

Specifically, it breaks activation and deactivation of conda environments. For example, I have a conda environment named conda_autoenv, which usually activated and deactivated using source activate conda_autoenv and source deactivate. Here is the bug:

➜  ~  ls -a test_autoenv 
.  ..  .env  .out
➜  ~  cat test_autoenv/.env 
source activate conda_autoenv
➜  ~  cat test_autoenv/.out 
source deactivate
➜  ~  cd test_autoenv 
discarding /home/nagasaki45/miniconda3/bin from PATH
prepending /home/nagasaki45/miniconda3/envs/conda_autoenv/bin to PATH
Error: too many arguments.
(conda_autoenv)➜  test_autoenv  cd ..
Error: too many arguments.
(conda_autoenv)➜  ~ 

Notice environment was activated, after all. However, the deactivation failed.

A possible solution I found, based on this answer in stackoverflow, can be found at https://github.com/Nagasaki45/autoenv/tree/better_source. With the proposed solution:

➜  ~  cd test_autoenv
discarding /home/nagasaki45/miniconda3/bin from PATH
prepending /home/nagasaki45/miniconda3/envs/conda_autoenv/bin to PATH
discarding /home/nagasaki45/miniconda3/envs/conda_autoenv/bin from PATH
(conda_autoenv)➜  test_autoenv  which python
/home/nagasaki45/miniconda3/envs/conda_autoenv/bin/python
(conda_autoenv)➜  test_autoenv  cd ..
discarding /home/nagasaki45/miniconda3/envs/conda_autoenv/bin from PATH
➜  ~

There are still issues with this solution, which I'm unable to understand. See the 3rd line after cd to the test_autoenv directory - it looks like the environment is not working as expected. On the other hand working in that envirnment is fine, everything works as expected.

check_and_run:8: permission denied

This is my .env file (similar as the example on README for NodeJS):

nvm use node
OLDPATH=$PATH
export PATH=`pwd`/node_modules/.bin:$PATH

When I enter to the directory I got the error this error:

> WARNING
> This is the first time you are about to source "/tmp/test/.env"

----------------

check_and_run:8: permission denied:

----------------

Are you sure you want to allow this? (y/N) y
N/A: version "N/A" is not yet installed.

You need to run "nvm install N/A" to install it before using it.

However, I'm able to source it without problem.
screen shot 2018-03-27 at 7 07 11 pm

I don't have idea why 😕.

Version: zsh 5.4.2 (x86_64-apple-darwin17.3.0)

bat pager interferes with output

When the contents of .in or .out are longer than the current terminal window, bat's pager activates, preventing the user from seeing the prompt. And when the user leaves the pager the code excerpt shown is empty, e.g.:

> WARNING
> This is the first time you are about to source "/tmp/autoenv/.in"

----------------

----------------

Are you sure you want to allow this? (y/N)

Consider adding -P (i.e. --paging=never) to the bat options:

bat --style="plain" -l bash "$1"

Env file is executed before environment is ready.

I use lukechilds/zsh-nvm for lazy loading nvm, if I have nvm use in my .env file, and cd to the directory in a running shell, autoenv works fine. However, if I split my terminal and it opens in the same directory, the point at which the .env file is executed is 'too early', and the nvm alias from the plugin is not yet available.

How to reuse configuration for siblling projects?

Hi,

I have several node projects living as sub directories in one directory. I created a .in file in this parent directory to set the PATH.

This setup works fine if I cd from outside of the parent directory into a project directory. But if I navigate within the project directories (which I do quite often), the script is not executed. (Which is the behavior as specified in the README.) But this means I end up with a PATH still pointing to the node_modules of the project where I came from.

Is there a better solution without having to specify an .in file in each project?

Thanks in advance

autoenv blocks when entering a subdirectory

how to reproduce

case 1

# new shell is ok
cd Documents
# cd never returns

case 2

# new shell is ok
cd /usr
# everything is ok
cd include
# cd never returns

Hint

I have added

  • echo "out $_AUTOENV_OLDPATH" on line
  • echo "in $_AUTOENV_OLDPATH" on line

and this is what is reported :

in  /usr/
in  /usr//
in  /usr///usr
in  /usr///usr/usr
in  /usr///usr/usr/usr
in  /usr///usr/usr/usr/usr
in  /usr///usr/usr/usr/usr/usr
in  /usr///usr/usr/usr/usr/usr/usr
...

The location of the Zsh Plugin Standard has changed

I noticed that this plugin (and probably others in this org) includes a link to the Zsh Plugin Standard at http://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html. But that URL is defunct now. I found a newer functional URL for the standard at https://z-shell.github.io/zsh-plugin-assessor/Zsh-Plugin-Standard. Note also that it seems the standard has now changed: the recommended 0= definition is more complex now. Just wanted to give you a heads up. See also ohmyzsh/ohmyzsh#10518.

.out does not seem to be executed

I have very simple .in and .out in the same directory.

% cat .in
echo 'autoenv: in'
% cat .out
echo 'autoenv: out'
%

Content of .out never seems to be executed:

~ ❯ zsh -f -d
% source ~/.local/share/zsh/bundle/zpm-zsh/colors/colors.plugin.zsh
% source ~/.local/share/zsh/bundle/zpm-zsh/autoenv/autoenv.plugin.zsh
% cd Sites/foo/

> WARNING
> This is the first time you are about to source "/Users/user/Sites/foo/.in"

----------------

echo 'autoenv: in'
----------------

Are you sure you want to allow this? (y/N) y
autoenv: in
% cd ..
%

ZSH version is zsh 5.8 (x86_64-apple-darwin19.3.0).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.