Timeline for bash: what's the difference between '< file' and taking input from a here-string which contains the file?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 30, 2024 at 15:31 | comment | added | humance | @QFO I did some of TomYan's test and they work on my system too. I'm running openssl version "OpenSSL 3.3.0 9 Apr 2024" Apparently the openssl team decided it is not necessary to seek at all to get the two pieces of input, and fixed it between openssl versions 3.0 and 3.3. This has nothing to do with shells or input redirection or "stdin". This is about a program using lseek(2) and you not giving it a regular file. | |
| May 30, 2024 at 15:30 | comment | added | humance | @QFO I'm sorry, you write "Ok, so nobody expects stdin to be seekable.". This is wrong. Seeking does not depend on whether a file "is stdin". "is stdin" means the file is at index 1 in the process file table. Lseek(2) depends on the file type. One can seek in " regular" files and in "character device files". One can not lseek(2) in a file of type pipe, socket, or fifo. (see gnu.org/software/libc/manual/html_node/Testing-File-Type.html for an explanation of a way to establish file type in C, and man7.org/linux/man-pages/man2/lseek.2.html for an explanation on lseek(2)) | |
| May 28, 2024 at 20:18 | comment | added | QF0 |
I'm not frustrated, and "everything" in Linux is a "file". I'm merely pointing out inconsistencies in what, on the face of it, appear to be the same usage of stdin and asking if there was a bash explanation. The comment from @TomYan demonstrates that what I expected does actually happen on certain systems.
|
|
| S May 25, 2024 at 13:26 | review | First answers | |||
| May 26, 2024 at 22:55 | |||||
| S May 25, 2024 at 13:26 | history | answered | humance | CC BY-SA 4.0 |