Automatically `cd` to the first optional argument passed to `lf` about lf HOT 13 CLOSED

@dumblob We can implement -- convention to handle filenames starting with -.

from lf.

I could use this for my implementation of bookmarks for example. But since it relies on another feature request, we shouldn't speculate too much about how it would work.

from lf.

Silly me, I just realized os.Args and flag.Args are different things and I don't have to rewrite flag parsing from stratch, sweet. This should now work as intended including the -- convention for directories startings with -. Sorry everyone for the long delay.

from lf.

I think this is not possible with the standard flag package so we may need to iterate arguments manually which is not difficult either. In the meantime, you can simulate that functionality with something like lf () { [ -n "$1" ] && cd "$1"; lf } in your shell configuration file or by adding a similar line to lf.sh.

from lf.

@lenormf did you mean passing the dir/file flag as the last argument or as the first argument? I'd prefer the last argument.

Anyway, it would be nice to have it behave as follows. If the argument is a directory or a symbolic link to a directory, lf would switch to it and focus the first line, done. But if the argument is a file or a symbolic link to a file, lf would first switch to the directory where the file/symbolic_link_to_a_file is (i.e. do cd "$(dirname "$argument")") and then focus the file/symbolic_link_to_a_file itself (i.e. focus the result of basename "$argument").

lf () { [ -n "$1" ] && cd "$1"; lf } ... lf.sh

Both leave the current shell environment polluted - in the first case the current directory stays changed even after lf exits (disregarding whether correctly or by crashing) and in the second, there is the tmp variable (disregarding whether the function is interrupted or not).

A safer solution taking into account these objections could be something like lf() (a="$1"; [ -d "$a" ] || a="$(dirname "$a")"; { if [ -d "$a" ]; then cd "$a"; else true; fi; } && exec lf)

from lf.

@dumblob Those are just examples. If you don't want to change the directory after you quit then your solution might work better for you. For tmp variable, I think you might be able to prefix it with local if you're using bash.

Flags are already prefixed with - and the other optional argument should point to the directory if any so I think we can implement this as a position invariant way.

from lf.

so I think we can implement this as a position invariant way.

Hm, and what about a file called e.g. -server? Or did I misunderstood something?

from lf.

@dumblob I don't think you misunderstood anything. It is just that somehow every issue you're involved with converges to more or less the same issue. I wonder do you have a file named -server somewhere?

from lf.

It is just that somehow every issue you're involved with converges to more or less the same issue.

Please accept my greatest apologies. It's not my intention. It's just that working on the core of RHEL (the base system, different packages, etc. - nearly everything critical), on real-time UNIX-based SCADA systems for power plants (yes, there were lots of different files and operations with them and file naming was crucial), etc. gave me a lesson.

I wonder do you have a file named -server somewhere?

I ran find "$HOME" -name '-server' and it returned 0 results. But find "$HOME" -name '*-server' returned 16 results (that's even beyond my expectation) and find "$HOME" -name '*-server*' 137 results. It's way too easy to create such a file by moving, cutting, or just mentioning the file with an unwanted space in the middle creating a -server file.

But from now on, I'll stop with file names fuss unless someone explicitly asks me.

from lf.

One more thought - how about just exposing completely all lf arguments (or at least all such lf arguments which are unknown to lf) through lf -remote 'args' returning a \0-separated list of them (\0 can be used on POSIX systems if lf implements lf -cmd read0 my_var proposed in #47 (comment) ). And leaving everything else up to the user who can then write her own handling of them - e.g. cd to the directory given as the first argument after --.

from lf.

@dumblob What is the use case for that?

from lf.

Exactly as @lenormf said. I myself would use it to cd to it if it's a directory and to cd to the dirname of it if it's not a directory. A second use-case of mine would be to leverage the filetype handling I've written inside of lfrc (lf would be a mime opener for anything - I know it's against the separation of concerns, but for me it's useful thanks to its portability across POSIX systems).

from lf.

This works now @lenormf I guess we could close this.

from lf.