Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Make the :doc command work even if lf is not in the PATH, add lf environment variable #1176

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
gokcehan merged 2 commits into from
Apr 1, 2023
Merged

Make the :doc command work even if lf is not in the PATH, add lf environment variable #1176

gokcehan merged 2 commits into from
Apr 1, 2023

Conversation

@ilyagr
Copy link
Collaborator

@ilyagr ilyagr commented Mar 26, 2023 •
edited
Loading

This makes lf export a new environment variable named lf with the path to the lf binary. So, scripts can use $lf instead of lf and work even in lf is not in the path.

The :doc command now executes $lf -doc (or %lf% -doc on Windows) instead of lf -doc. I'd appreciate it if somebody could double-check that this works on Windows.

If Go fails to find a path to the lf binary, $lf is set to the string lf so that it still works if lf is in the PATH. (Though, from looking at the source briefly, Go might already look in the path if it couldn't find the binary normally)

Before this change, :doc did not work if lf is not in the PATH. This is likely to be a problem for new users who are trying out lf and need docs the most.

Moreover, if a developer makes some changes to the docs and runs lf with go run ., :doc would previously return the docs for the version of lf in the PATH (if any) instead of what is expected.

Another motivation for this is to make adding command-line options like lf -buffers (see #1152 (comment)) or lf -marks, if we decide it's a good idea in the future, work regardless of whether lf is in the PATH.

@ilyagr
Export a $lf environment variable with path to lf binary
1845c15 
If Go fails to find a path to the lf binary, `$lf` is set to the string `lf` so
that running `$lf` in scripts gives a reasonable error message.
@ilyagr ilyagr force-pushed the doc branch 3 times, most recently from bbed4ac to 97dcf77 Compare April 1, 2023 02:51
@ilyagr
Copy link
Collaborator Author

ilyagr commented Apr 1, 2023 •
edited
Loading

I updated the PR to work if path to lf contains spaces. Again, I tested it for linux, but testing for Windows is TODO.

Turns out Windows has "evaluation" version one can run for free in a VM, so maybe I'll try that.

Update: Tried it on Windows. It doesn't seem to work with spaces in the directory. "%lf%" -doc works in cmd.exe, but !"%lf%" -doc doesn't work from lf. Weird.

I changed the Windows command back to %lf% -doc for now.

@ilyagr
Make the :doc command work even if lf is not in the PATH
7710610 
Previously, `:doc` executed `lf -doc`. Now, it executed `$lf -doc` or `%lf%
-doc`.

Before this change, `:doc` did not work if `lf` is not in the PATH. This is
likely to happen to new users who are trying out `lf` and need docs the most.

Moreover, if you made some changes to the docs and ran `lf` with `go run .`,
`:doc` would return the docs for the version of `lf` in the PATH instead of
what is expected.
@gokcehan
Copy link
Owner

gokcehan commented Apr 1, 2023

@ilyagr Looks good, thanks for the patch.

On a related note, I think we simply used os.Args[0] instead of os.Executable() for a similar purpose in startServer in main.go though I don't remember if there was a reason for using one over the other one.

@gokcehan gokcehan merged commit 27ab67a into gokcehan:master Apr 1, 2023
@ilyagr ilyagr deleted the doc branch April 7, 2023 00:05
gokcehan added a commit that referenced this pull request Apr 30, 2023
@gokcehan
update doc
2c86577 
cc #1176
@ilyagr ilyagr mentioned this pull request Jun 17, 2023
Merged
@joelim-work
Copy link
Collaborator

joelim-work commented Jun 18, 2023 •
edited
Loading

On a related note, I think we simply used os.Args[0] instead of os.Executable() for a similar purpose in startServer in main.go though I don't remember if there was a reason for using one over the other one.

BTW, when I was working on #1309, I have found that os.Args[0] and os.Executable() can have different results on Windows, and possibly the root cause of #1097 is because the server fails to start properly if the lf path is wrong.

Update: I have found that for Windows, if lf isn't in PATH, you have to use .\lf and not lf, otherwise the server won't start properly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@ilyagr @gokcehan @joelim-work