5 Nisan 2021 Pazartesi tarihinde Oğuz <oguzismailuy...@gmail.com> yazdı:
> 5 Nisan 2021 Pazartesi tarihinde Chet Ramey <chet.ra...@case.edu> yazdı: > >> On 4/5/21 3:14 PM, Oğuz wrote: >> >>> 5 Nisan 2021 Pazartesi tarihinde Chet Ramey <chet.ra...@case.edu >>> <mailto:chet.ra...@case.edu>> yazdı: >>> >>> There's no guarantee that file descriptors opened with socket(2) >>> show up in >>> /dev/fd. Bash doesn't emulate /dev/fd if the system provides it, so >>> it's up >>> to the OS on those systems whether they do or not. >>> >>> It doesn't generate that error on macOS, for instance, which has >>> /dev/fd. >>> >>> >>> I can reproduce the error, but it is coming from `tee', which tries to >>> open `/dev/fd/??' as a regular file whereas it is a socket, and gets an >>> ENXIO error. >>> >> >> That's what I mean. What happens on a system that implements /dev/fd and N >> in /dev/fd/N is a valid descriptor? There are varying answers. >> >> The simplest /dev/fd drivers just dup the file descriptor passed as an >> argument. There are progressively more complex implementations. It's >> not guaranteed they treat descriptors returned by socket(2) the same as >> those returned by open(2), even to whether they show up in /dev/fd at all. >> >> If you don't have /dev/fd, all bets are off, of course, but then I'd guess >> the error would be ENOENT. > > > Yeah. If you have /dev/fd though you have /dev/fd/1 (and even > /dev/stdout), so OP could have done `echo a | tee /dev/fd/1 > >/dev/tcp/host/port' instead > That should have been `echo a | tee /dev/fd/3 3>&1 >/dev/tcp/host/port' > > >> >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ >> > > > -- > Oğuz > > -- Oğuz
