honor environment variables in find-files

[slymz]

~ is for home / is for root what token is for /my/supercomputer/scratch/directory/that/keeps/changing?

Err, that'd be an exported environment variable, conveniently available wherever needed, for example vanilla find-files honors these, type and just dired into.

Can helm find files also support environment variables?

[thierryvolpiatto]

slymz notifications@github.com writes:

~ is for $HOME / is for root what token is for /my/supercomputer/scratch/directory/that/keeps/changing?

Err, that'd be an exported environment variable, conveniently available wherever needed, for example vanilla find-files honors these, type and just dired into.

Can helm find files also support environment variables?

Sorry I don't understand what you are expecting from helm-find-files. "~" is supported and "/" also, what else do you want ?

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[tuhdo]

I think he meant that if some environment variables contain some paths, when put it in helm-find-files, it should recognize the paths in the environment variables. This is the behaviour of stock find-file.

[thierryvolpiatto]

Tu Do notifications@github.com writes:

I think he meant that if some environment variables contain some paths, when put it in helm-find-files, it should recognize the paths in the environment variables. This is the behaviour of stock find-file.

You mean handling (substitute-in-file-name "$HOME") ?

Don't know how this could be useful in the real life. Never used this feature of find-file in ten years usage of emacs.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[slymz]

Sorry, apparently the original post was not clear.

Feature: If I type in an environment variable to the mini-buffer in helm-find-files, e.g. $TMP/foo.txt, then helm-find-file goes to whatever path $TMP/foo.txt resolves to, not the literal \$TMP/foo.txt. That is the behavior of stock find-file.

I'll enumerate a number of real life scenarios for you:

1. Supercomputers. These are shared systems with a lot of capability. One capability is special mounts points with high capacity, high performance files systems. Mount point is neither /tmp/ nor /home or anything standard. The full path is system dependent and session dependent, and the full path is ugly, something like: /lustre/medusa/$USER. That path is provided in your interactive session as an environment variable, e.g. $SCRATCHDIR. I am not making any of this up: see e.g. https://www.nics.tennessee.edu/computing-resources/file-systems.
2. Mounts in a company network: There are preconfigured Linux machines that you are given, which have local and NFS based mounts. Users have scratch space that are shared, local drives that are fast, windows mounts, software mounts all kinds of crap. These have somewhat stable but otherwise ugly path names, e.g. /local/ssd/15T/foouser/. There are standard login shell environment variables, e.g. $s == /mnt/worldwide/timbuktu/rocketproject/goaway/user1. So that you remember the $s, not the abomination it is set to.
3. Your own definition of local workflow. This is a personal preference, but why the heck not? You have 10s of projects that you work on, some of them are really active and you don't want random symlinks all over the place, or symlink does not give me what I want (I want to see the full path). One solution is to add environment variables in your login script, e.g. p1=$HOME/work/proposal/this/path/sucks/but/thats/what/you/asked. Then I use my silly but simple environment variable $p1, which is only two characters, then switch and open the damned path.

[tuhdo]

For option 3, maybe you want to look at Projectile and Helm Projectile (the same repo but different packages on MELPA): https://github.com/bbatsov/projectile . It remembers anything that it recognizes as a project, so you can switch between them easily. If your project is not one that it recognizes, putting an empty .projectile file makes it treat that directory as a project. You can see Helm Projectile demos.

[slymz]

Thanks Tuhdo, I am already using projectile. Extremely useful stuff. And your pages were are amazingly useful especially. So thanks, really!

I find it an overkill to sprinkle random directories with .projectile files, but that is useful in its own right, so thanks for the tip. But generally that is not quite possible, for examples 1 and 2 that I tried to explain above, most of these directories are read only and telling projectile that these are projects is a hack at best.

[slymz]

... sorry you already said "for option 3". That is not bad I'll try to adopt it. But environment variables are still useful, as they are more generally available (e.g. outside of emacs)

[thierryvolpiatto]

slymz notifications@github.com writes:

Sorry, apparently the original post was not clear.

Thanks for explanation.

Feature: If I type in an environment variable, e.g. $TMP/foo.txt, then helm-find-file goes to whatever path $TMP/foo.txt resolves to, not the literal \$TMP/foo.txt. That is the behavior of stock find-file.

Ok done, even better you can add (paste) at end of pattern a env var and as soon you add the final "/" it will expand to the env var:

e.g if you are at: /home/you/foo/bar/baz/ if you paste or enter $HOME after: /home/you/foo/bar/baz/$HOME and you add the final "/" /home/you/foo/bar/baz/$HOME/ helm will expand to /home/you/

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[slymz]

Awesome!

[Nidish96]

This works for bash. I recently switched to fish (chsh -s /usr/bin/fish) and the functionality was lost. Yes, I set my environment variables in .config/fish/config.fish with set VAR path. Can something be done?

[thierryvolpiatto]

Nidish96 notifications@github.com writes:

This works for bash. I recently switched to fish (chsh -s /usr/bin/fish) and the functionality was lost. Yes, I set my environment variables in .config/fish/config.fish with set VAR path. Can something be done?

I don't think I can do something at helm level, but you can perhaps do this at emacs level using perhaps shell-file-name (not sure and untested) ? But be careful with these exotic shells, you may have problems elsewhere with such shell-file-name settings.

-- Thierry

[michael-heerdegen]

@Nidish96 AFAIU this functionality doesn't invoke any shell at all to do the job. We use the environment variables in the Emacs environment (see "getenv" and "process-environment"). The concept of environment variables is independent from shells. If Helm (and Emacs) don't see the environmental variable bindings you establish in your fish shell, I think you don't export them correctly.

[michael-heerdegen]

Oh, and don't bind "shell-file-name" to fish. This will break a lot of Emacs commands that call shell commands internally because they work only with a sh compatible shell. And AFAIU it won't solve your problem.

[thierryvolpiatto]

Michael Heerdegen notifications@github.com writes:

@Nidish96 AFAIU this functionality doesn't invoke any shell at all to do the job. We use the environment variables in the Emacs environment (see "getenv" and "process-environment"). The concept of environment variables is independent from shells. If Helm (and Emacs) don't see the environmental variable bindings you establish in your fish shell, I think you don't export them correctly.

Thanks Michael for explanations.

-- Thierry

[Nidish96]

@michael-heerdegen what about this - I do M-! echo $FEMDIR and the value of the variable is displayed. It just doesn't expand in helm. I type .../$FEMDIR/ and it just reverts to /$FEMDIR and doesn't expand any more - I can't type any more subdirectories either, each time I type a slash it goes back to /$FEMDIR. Strangely, $HOME does not have issues. Can this have anything to do with the fact that fish declaration syntax (set VAR val) is not the same as in bash(export VAR=val)? The documentation of process-environment says "... Each element should be a string of the form ENVVARNAME=VALUE.". Note that the fish syntax does not involve an equal-to sign.

PS: FEMDIR is a variable I've set to the location of a directory I have a project in

[michael-heerdegen]

Nidish96 notifications@github.com writes:

Can this have anything to do with the fact that fish declaration syntax (set VAR val) is not the same as in bash(export ...)?

Yes, it can. At least you should use the -x flag (aka "export"), I guess.

Did you try the fish internal help? "man set" in the fish shell shows you a help page for the fish command "set".

[Nidish96]

Oh - I feel stupid now - the -x flag worked!

[michael-heerdegen]

Nidish96 notifications@github.com writes:

Oh - I feel stupid now - the -x flag worked!

Ok, great (I mean, great that it worked).

Generally, IMO fish is the shell for people that are unable to cope with a shell like bash - at least in my case, this is the reason why I chose it. There are not many more lessons to learn, I think. But for Emacs, if you choose fish as your default shell, be sure to make "shell-file-name" point to a standard conform shell like bash, else things like "find-dired" will break. AFAICT fish doesn't work so well in shell or term anyway.

[Nidish96]

Well, in emacs I use eshell. The autocomplete and suggestion features in fish are indeed pretty good though.