-
-
Notifications
You must be signed in to change notification settings - Fork 824
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
In cygwin, fd output displays backslash instead of forward slash #153
Comments
Hi, thank you for your feedback. Could you please give a little bit more details (fd version, operating system, etc.)? Why do you think fd should output |
Most tools in cygwin output a / separator, but fd uses \ instead... |
was fd compiled with cygwin, or as a windows binary? |
https://github.com/sharkdp/fd/releases/download/v5.0.0/fd-v5.0.0-x86_64-pc-windows-gnu.zip So I guess it's understandable that it's output shows windows backslash convention. |
We could potentially change this, but I'm not sure if It says |
I was actually curious about this. When compiled on windows fd will always replace forward slashes with back slashes. Doesn't PathBuf already format the slashes depending on the platform? |
@sharkdp, it looks like fd is using As a side note from what I can tell |
I was running fd v4.0.0 and then noticed there was a newer version and so I installed that.. hence the discrepancy. I don't have rust installed. |
It looks like it's hard-coded for the different operating systems: If I may, I'd like to repeat my question from above:
|
@Doxterpepper Without Cygwin path translation, your patch might complicate things. fd will not be able to use Cygwin only paths like |
@ghuls, |
@sharkdp, Cygwin is supposed to be a posix compliment environment so the forward slashes are always going to be preferred in any application running in Cygwin. Our options are to either not do anything and let the user handle it with cygpath or something else, or to check for a environment variable such as HOME which is normally only defined in a Unix like environment to determine if we should use forward or back slashes. I think my patch may not be preferred now that I think about it because if the user for some reason did |
IMHO, (Selfishly) I like the idea of having basic default fd functionality being a direct drop-in replacement for basic find functionality. So by default it should mimic cygwin's find output. |
For the record Windows officially supports forward slash. According to Microsoft:
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx |
I'm a Cygwin user, and for example the reason I'm using I just found out about P.S. There is another popular (rather minimal) UNIX-like environment |
Ok, it looks like a cygwin-specific build could be an option. I would like to avoid pulling in more dependencies (even optional), but if this can be configured using compile-time flags, it sounds like a good option to me. I will likely not find the time to work on this, but if someone wants to contribute, I'm happy to assist / discuss. |
I think I could handle it (although I don't know Rust). What is the best channel for discussion? |
Great! You could open a ("work-in-progress") pull request and we can discuss there or we can just use this ticket. Whatever you prefer. |
I'm a little surprised there isn't a x86_64-pc-windows-cygwin target for rustc. |
For what it's worth, I sometimes use something similar to the following in Cygwin/MSYS flavors as a workaround: fd() {
command fd "$@" | cygpath --ignore --file -
} ...defined in .bashrc or equivalent. It streams the output through Considering what |
fyi: ag shows the expected slash when run in cygwin too. https://github.com/ggreer/the_silver_searcher/search?utf8=%E2%9C%93&q=cygwin&type= |
Is there an appropriate working group we could share this issue with? |
the CLI working group seems appropriate. https://internals.rust-lang.org/t/announcing-the-cli-working-group/6872 |
|
@ErichDonGubler Interesting. II have not considered it, but I'm open to adding this to |
@sharkdp: I know that @BurntSushi actually decided to stick a fork in finding a "real" solution for the problem because it was so time-intensive. Using a shim above like @cyrossignol is something I also do for my MSYS2 setup -- while not totally palatable, it at least makes things bearable and is a good partial solution to this problem. The crux of the issue here is that the Cygwin/MSYS2 environment sidesteps the issue of portability like Rust needs to deal with here by creating a different compilation environment. Many C/C++ solutions can straightforwardly solve this problem by recompiling with the MinGW version of |
Released in v7.4.0. |
No description provided.
The text was updated successfully, but these errors were encountered: