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

Can't open file descriptors in /proc/[###]/fd #266

Closed
aseering opened this issue Apr 25, 2016 · 16 comments

Comments

Projects
None yet
7 participants
@aseering
Copy link
Contributor

commented Apr 25, 2016

I'm trying to get bash's process substitution working. It's a few steps shy of working, but, one big one:

The file descriptors under /proc/self/fd aren't openable. They are listed as writeable, but the "open()" libc call is returning -1 when I try to open them.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2016

This was discussed in passing by #91

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2016

Here's a gist of a .c file which, if loaded into a Linux (or Windows-Bash) binary, roughly emulates the desired behavior of these file descriptors. It's good enough to get bash process substitution working, anyway.

It's trying to make /dev/fd work, which is what bash process substition uses and which doesn't exist at all in Windows-Bash. If you want /proc/self/fd, modify line 38 accordingly.

@benhillis

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

Looks like we're missing the below symlinks in the /dev directory. I just filed an internal bug and will get these added to our dev branch today.

lrwxrwxrwx   1 root root          13 Apr 29  2016 fd -> /proc/self/fd/
lrwxrwxrwx   1 root root          15 Apr 29  2016 stderr -> /proc/self/fd/2
lrwxrwxrwx   1 root root          15 Apr 29  2016 stdin -> /proc/self/fd/0
lrwxrwxrwx   1 root root          15 Apr 29  2016 stdout -> /proc/self/fd/1

Thanks for reporting this!

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2016

Thanks for the reply, and the quick action! Those symlinks will be very helpful.

Once you have the symlinks, is there any chance you could run the following one-line bash command real quick, as a test case?:

cat <(echo 'hello world') > >(tee tmp.txt)

It should print "hello world" to the terminal, and write a file "tmp.txt" that contains the same string. Works fine on Ubuntu Linux. Doesn't work on my Windows Bash system, even if I modify bash to use /proc/self/fd rather than /dev/fd (which is in effect what adding those symlinks does).

My workaround (above; link to gist) fixes the issue by aliasing open("/proc/self/fd/NNN") to dup(NNN).

If this is already fixed on your end, great! I await the next build :-) If not, just making sure you know what I'm seeing.

@benhillis

This comment has been minimized.

Copy link
Member

commented Apr 25, 2016

Something interesting is going on here that I'll need to debug further. I'm getting an error about cat: /dev/fd/63: No such file or directory even though I've verified that the /dev/fd symlink is working correctly. It could be a problem with the tee system call or something else, I'll continue looking into this.

@benhillis benhillis added the bug label Apr 26, 2016

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented Apr 27, 2016

Thanks for looking at this! I'll be curious to hear what you find.

@benhillis

This comment has been minimized.

Copy link
Member

commented Apr 27, 2016

@aseering - Dug into this a bit more and we're not correctly handling opening pipes by the procfs symlinks correctly (for example open("/dev/fd/1") or open("/proc/self/fd/1"). I've filed a bug internally to track this and we have a good idea of how to fix it.

@benhillis

This comment has been minimized.

Copy link
Member

commented May 16, 2016

This was fixed in our development branch recently and the fix will be making its way to the Windows Insider fast ring.

@aseering

This comment has been minimized.

Copy link
Contributor Author

commented May 17, 2016

Thanks!

@pefoley2

This comment has been minimized.

Copy link

commented May 28, 2016

Appears to still be an issue in build 14352.
Hopefully this fix will land in the next release.

@AbhimanyuAryan

This comment has been minimized.

Copy link

commented May 31, 2016

who says this has been fixed @benhillis I am trying to install rvm and I still have this issue on 14352

cat: /dev/fd/63: No such file or directory
cat: /dev/fd/63: No such file or directory
The downloaded package for https://rubies.travis-ci.org/ubuntu/14.04/x86_64/ruby-2.3.1.tar.bz2,
Does not contains single 'bin/ruby' or 'ruby-2.3.1',
Only '' were found instead.
@mcornella

This comment has been minimized.

Copy link

commented May 31, 2016

@AbhimanyuAryan he didn't say it was fixed on 14352, but on their internal dev branch. It's probably not yet released.

@AbhimanyuAryan

This comment has been minimized.

Copy link

commented May 31, 2016

@mcornella my bad so when are we expecting the update? I have un-installed Linux to get Windows and it's still not here. Microsoft said it quite clearly "Ubuntu on Windows" 😥😕

@benhillis

This comment has been minimized.

Copy link
Member

commented May 31, 2016

@AbhimanyuAryan - Sorry for the confusion, the fix will be an insider release soon. We don't have any control over when Insider builds are released so I apologize that I can't give a more firm timeline.

@AbhimanyuAryan

This comment has been minimized.

Copy link

commented May 31, 2016

@benhillis you should explain that to Microsoft Insider team that it's "WindowsOnBash" because of which people are making switch not Windows. So they can set the priorities right😞

Btw you guys are doing great work :)

@stehufntdev

This comment has been minimized.

Copy link
Collaborator

commented Jun 8, 2016

Insider build 14361 that was just released has the fix for this, and I doubled checked the one line repro above.

@stehufntdev stehufntdev added fixed and removed fixinbound labels Jun 8, 2016

@russalex russalex closed this Jun 13, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.