Skip to content
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.

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

Feature request: add option to redirect stderr to a file #152

Closed
carl-mastrangelo opened this issue Nov 4, 2018 · 4 comments
Closed

Feature request: add option to redirect stderr to a file #152

carl-mastrangelo opened this issue Nov 4, 2018 · 4 comments

Comments

@carl-mastrangelo
Copy link

When sshfs is not run in the foreground, it appears that stderr is redirected to /dev/null. It would be nice if there was an option to forward this to a file, to make it easier to debug.

@Nikratio
Copy link
Contributor

Thanks for the suggestion! It's not clear to me what advantage this has over running in the foreground (potentially redirecting stderr to some file before). Could you elaborate?

@carl-mastrangelo
Copy link
Author

carl-mastrangelo commented Dec 31, 2018

@Nikratio

The main thing to me was discoverability (i.e. making a command line option makes the user aware that it's possible). It wasn't obvious from the --help page where stdout went, or that it was related to being in the background or foreground. After looking through the source code, I eventually found where ssh's output was redirected, but it would have been easier if I didn't have to.

Another alternative is to call out where the pipes are connected in the man page. That would have given me the breadcrumb I needed to find out that it was foreground that I actually wanted.

Thoughts?

@Nikratio
Copy link
Contributor

Nikratio commented Jan 1, 2019

It's not mentioned anywhere in the SSHFS docs because it's a Unix default. If one process starts another, it gets the same stdin/stdout :-).

Happy to add it to the manpage though if you want to create a pull request.

@Nikratio
Copy link
Contributor

I'm closing this issue for now. This isn't meant to be a rejection of the idea itself, it's just that there is little point in keeping enhancement/wishlist requests in the bug tracker that no-one intends to work on. (I want to use the tracker as a tool to manage ongoing work rather than a database of possible enhancements).

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

No branches or pull requests

2 participants