Timeline for Pipes Aren't Working: C Programming in the Windows Console [closed]
Current License: CC BY-SA 4.0
27 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 29 at 6:32 | comment | added | Luis Colorado | I have compiled your (corrected code) with Visual Studio for Windows and If I run it with cmd.exe it works as expected, while running your command line under PowerShell gives the error about 'C:\B' not existent. This comment just to illustrate that you will probably be using the wrong shell, or using windows approximations to POSIX behavior. (I had to add a #define _CRT_SECURE_NO_WARNINGS to the source, to avoid an error, claiming fopen() being an unsecure function (????) | |
| Aug 29 at 5:32 | comment | added | Luis Colorado | fclose("tmpstdin.txt"); is incorrect, you should fclose(fp); instead. | |
| Aug 28 at 14:35 | comment | added | John Bollinger | If it happens that your broken C implementation erroneously sets both the eof indicator and the error indicator on the read end of the pipe under such circumstances, then perhaps you could work around it by checking feof() instead of ferror(). | |
| Aug 28 at 14:32 | comment | added | John Bollinger | Ok, and that doesn't make any sense at all. Even more reason to blame the implementation. A broken pipe error should occur only when writing to a pipe (that no longer has any readers), never when reading from one. Reading from a pipe with no more data and no writers should just indicate end-of-file. | |
| Aug 28 at 11:30 | history | closed | John Bollinger user4157124 gnat | Not suitable for this site | |
| Aug 27 at 21:39 | history | edited | user31366153 | CC BY-SA 4.0 | deleted 43 characters in body |
| Aug 27 at 21:15 | comment | added | user31366153 | @JohnBollinger A call to perror() was placed right after that first while loop. It says "Broken pipe" for stdin stream. | |
| Aug 27 at 21:07 | review | Close votes | |||
| Aug 28 at 11:34 | |||||
| Aug 27 at 20:59 | comment | added | user31366153 | @JohnBollinger I'm starting to think the same thing, about it being a compiler issue. As an aside, if you want to see what I'm trying to accomplish with all this, you can have a look athttps://github.com/psj23/permutit/blob/main/permutit.c | |
| Aug 27 at 20:56 | comment | added | John Bollinger | Note that on error, fgets() should not only return a null pointer, but also set errno appropriately. It would be appropriate and possibly revealing to use perror() to get a more meaningful diagnostic out of that than the generic ones you are now outputting. | |
| Aug 27 at 20:49 | comment | added | John Bollinger | Anyway, the issue must have something to do with your compiler and / or execution environment. I do not reproduce it in my environment, and I don't see any reason to think I would. Do note the genuine error described in your answer (as I see you have done), but even that would not explain the behavior you describe. | |
| Aug 27 at 20:34 | comment | added | John Bollinger | Whoever told you that you needed to process strings entered from the keyboard in such a way either didn't know what they were talking about or was lying to you. Perhaps lying benevolently, to point you in a direction that they thought would be productive. Any way around, it's not true. | |
| Aug 27 at 20:30 | comment | added | user31366153 | @JohnBollinger: Firstly, thank you for your insights. As for why the temporary file: I was told that if I wanted to process strings entered at the keyboard, I would have to first save the inputted lines to a file, count the lines, then allocate the array using malloc(). Unfortunately, the example I gave is simplified and doesn't really touch upon that aspect. It was just to show that I'm having trouble piping at the command line. Note on the compiler: Yes, I know it's an oldie :) While they call it C++, it's actually a C89 conformant C compiler as well. I also test everything with gcc. | |
| Aug 27 at 20:11 | answer | added | greg spears | timeline score: 2 | |
| Aug 27 at 19:57 | comment | added | John Bollinger | Another side note: since you evidently want a fixed-length line buffer of modest size, it is needlessly complicated to allocate that dynamically. Just declare it as an array: char s[BUFLEN]; | |
| Aug 27 at 19:51 | comment | added | John Bollinger | C is not C++, nor a subset thereof. Do not use C++ compilers for C code. And I cannot recommend 25-year-old compilers at all for modern systems. I'm not confident that the compiler is responsible for your issue, but even if it isn't, you will be well served by switching to something released this millennium. Ideally, something released this decade. | |
| Aug 27 at 19:45 | comment | added | user31366153 | @JohnBollinger: It always fails at the first while loop. It fails on both the stdin and fp streams (I reveresed the order of ferror() checks to see if both streams were affected and they both are). I'm compiling for Windows using Borland C++ 5.5 Free Command Line Tools. Interestingly, things seem to work fine when compiled and run under Linux, where piping gets me the expected result. It's just Windows console giving grief. | |
| Aug 27 at 19:42 | comment | added | John Bollinger | @PeterS.Jaworski, you can work with piping without creating regular files. And, separately, you can work with unknown-length input without first checking its length. Slurping a whole file into memory at once has bad code smell, but if you must do that then an approach involving strategic use of realloc() would be conventional. | |
| Aug 27 at 19:39 | comment | added | John Bollinger | Side note: this code contains a bug that is (probably) not related to any I/O errors: it will terminate early after encountering a line that is exactly 80 characters long (excepting the line terminator). Same for a 160-character line, 240-character, etc.. This is because fgets() is reading up to 80 characters at a time, and leaving any additional ones unread. If a line is exactly 80 characters long then those 80 will be read by one fgets() call, and on the next call, only a newline will be read. | |
| Aug 27 at 19:37 | comment | added | user31366153 | @JohnBollinger I'm planning on using this method in another program to fill a vector (char *[]) with strings, but that vector must first be allocated with malloc(), which will require counting of lines entered. This piece of code is essentially a test for that bigger project, and I'd really like it to work with piping. | |
| Aug 27 at 19:34 | comment | added | John Bollinger | Which I/O error does it fail with, @PeterS.Jaworski? That is, which check fails? Or is it different ones on different runs? | |
| Aug 27 at 19:27 | comment | added | John Bollinger | But what's the point of the temp file, @PeterS.Jaworski? Why not write input lines directly to stdout instead of first buffering them in a file? | |
| Aug 27 at 19:25 | comment | added | user31366153 | @dbush: The condition of the first while loop has fgets() reading from stdin; the body of the loop has it writing to tmpstdin.txt. Perhaps the code is unclear or am I missing something? | |
| Aug 27 at 19:24 | comment | added | John Bollinger | Generally speaking, you should check ferror() only when the return value of a function call suggests that there might be something to find, and it's important to distinguish between errors and end-of-file. Although it's not wrong to check at other points, it does needlessly complicate your code. | |
| Aug 27 at 19:19 | history | edited | John Bollinger | CC BY-SA 4.0 | Formatting; minor editing |
| S Aug 27 at 19:13 | history | asked | user31366153 | CC BY-SA 4.0 | |
| S Aug 27 at 19:13 | history | created from staging ground | Graduated from staging ground post. |