5 ms·

> tree I agree, tree is great. It can be somehow replicated by using "find .", if you are in a hurry. > bat If you need that functionality, why don't you op

> tree I agree, tree is great. It can be somehow replicated by using "find .", if you are in a hurry. > bat If you need that functionality, why don't you open the file with vim, for example? > rg - better grep Grep is pretty nifty, I don't see how could it be improved. What is the main advantage of of rg over grep? > direnv - local environment variables I read the manpage for direnv and I was really scared. What is it for? I never used an .envr. If I need to see my environment I can simply use "env". What is it missing?

gpanders 6y ago
Re: bat. I agree with you, I don’t get the hype over this program either. It’s pretty easy to configure 'less’ to use syntax highlighting and ‘less’ is installed basically everywhere. The main advantage of rg is how much faster it is than grep. It’s WAY faster. I don’t use direnv but I have colleagues who do. I think the idea is that it can set environment variables/run arbitrary commands when you cd into a certain directory (such as activating a Python virtual env, for instance).
- haberman 6y ago
  I also like that rg's default mode is to search all files recursively, skipping binary files and honoring .gitignore. 90% of the time this is just what I want.
breuleux 6y ago
direnv is super useful if you're working in Python and have multiple projects: you can add an .envrc file that activates the right virtualenv whenever you enter a directory. It's one less thing to worry about. I figure you can also use it in conjunction with `module load` to automatically load the right module when you enter a project's directory. Modules are used in many computing clusters to manage environments. Also direnv will never execute an .envrc without permission, you need to run `direnv allow` whenever there is a new or newly modified .envrc.
- flukus 6y ago
  I've got a hand rolled direnv that's quite simple: function lenv { path=$PWD while [[ ! -f "$path/.env" && "$path" != '/' ]]; do path=$(dirname "$path") done if [ -f "$path/.env" ]; then source "$path/.env" fi } function cd { builtin cd "${@}"; lenv; } It lacks the security but it works recursively and allows more than just environment variables. A common script I have is to automatically build for instance: here=$(dirname ${BASH_SOURCE[0]}) function autobuild { ( mkdir -p build cd $here/build ../configure while true; do make && make check inotifywait -qr -e close_write,delete $here/src $here/test $here/Makefile.am done ) } I've tried generalizing the latter but between different targets, different build systems, different projects structures etc, copy and pasting something like this per project is the least worst option.
  - breuleux 6y ago
    direnv does allow more than just environment variables, you can run arbitrary commands. Personally I wouldn't run potentially expensive commands like building the project, but if that's really what's best for your workflow, it can be done. If there is no .envrc in the directory it will look for one in the parent directory, but it won't activate more than one. Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory.
    - flukus 6y ago
      > Personally I wouldn't run potentially expensive commands like building the project My above example wasn't running the command, just defining it to be run manually. The .env becomes a dumping ground for all sorts of project specific stuff. The docs say direnv doesn't support this. > Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory. I've thought of adding this, but apart from a couple of things I reset manually I haven't really found the need.

gpanders 6y ago

Re: bat. I agree with you, I don’t get the hype over this program either. It’s pretty easy to configure 'less’ to use syntax highlighting and ‘less’ is installed basically everywhere. The main advantage of rg is how much faster it is than grep. It’s WAY faster. I don’t use direnv but I have colleagues who do. I think the idea is that it can set environment variables/run arbitrary commands when you cd into a certain directory (such as activating a Python virtual env, for instance).

haberman 6y ago
I also like that rg's default mode is to search all files recursively, skipping binary files and honoring .gitignore. 90% of the time this is just what I want.

breuleux 6y ago

direnv is super useful if you're working in Python and have multiple projects: you can add an .envrc file that activates the right virtualenv whenever you enter a directory. It's one less thing to worry about. I figure you can also use it in conjunction with `module load` to automatically load the right module when you enter a project's directory. Modules are used in many computing clusters to manage environments. Also direnv will never execute an .envrc without permission, you need to run `direnv allow` whenever there is a new or newly modified .envrc.

flukus 6y ago
I've got a hand rolled direnv that's quite simple: function lenv { path=$PWD while [[ ! -f "$path/.env" && "$path" != '/' ]]; do path=$(dirname "$path") done if [ -f "$path/.env" ]; then source "$path/.env" fi } function cd { builtin cd "${@}"; lenv; } It lacks the security but it works recursively and allows more than just environment variables. A common script I have is to automatically build for instance: here=$(dirname ${BASH_SOURCE[0]}) function autobuild { ( mkdir -p build cd $here/build ../configure while true; do make && make check inotifywait -qr -e close_write,delete $here/src $here/test $here/Makefile.am done ) } I've tried generalizing the latter but between different targets, different build systems, different projects structures etc, copy and pasting something like this per project is the least worst option.
- breuleux 6y ago
  direnv does allow more than just environment variables, you can run arbitrary commands. Personally I wouldn't run potentially expensive commands like building the project, but if that's really what's best for your workflow, it can be done. If there is no .envrc in the directory it will look for one in the parent directory, but it won't activate more than one. Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory.
  - flukus 6y ago
    > Personally I wouldn't run potentially expensive commands like building the project My above example wasn't running the command, just defining it to be run manually. The .env becomes a dumping ground for all sorts of project specific stuff. The docs say direnv doesn't support this. > Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory. I've thought of adding this, but apart from a couple of things I reset manually I haven't really found the need.