edf2csv 0.5.117 → 0.5.119

package/CHANGELOG.md

@@ -3,6 +3,69 @@
 Notable changes to edf2csv. Versions follow [semantic versioning](https://semver.org); while the
 major version is 0, a minor bump may contain breaking changes.
 
+## 0.5.119
+
+### Fixed: a paragraph written into the middle of a quoted warning
+
+The `CONTINUOUS_LIAR` entry in warnings-and-errors quotes what the run prints. What the page
+showed was this:
+
+```
+warning: This file is marked continuous (EDF+C), but 2 of its 3 data records say they start
+         somewhere other than where continuity puts them.
+
+A BDF+ file gets its own spelling — `BDF+C` and `BDF+D` — the same as the discontinuous entry
+above. Until 0.5.105 this half of the code printed the EDF markers whatever the format, so a
+BDF+ recording was told about a string it does not contain and pointed at a marker BDF+ does
+not define.
+         Times are written as if the records were contiguous, which is what EDF+C means.
+         If the recording really has gaps, the file should have been marked EDF+D.
+```
+
+An English sentence, backticks and all, inside the code block, between the warning and its own
+advice — so the two indented lines read as hanging off the paragraph rather than off the
+warning, and the warning itself reads as ending mid-sentence. The paragraph is true and belongs
+on the page; it is now below the block instead of inside it.
+
+A hint is joined to its message by nothing but that indent. So an indented line in a quoted
+diagnostic has to have a diagnostic directly above it, and a test now holds every such block on
+every page to that. A blank line inside one is still fine — the mixed-rate example shows a
+warning, a blank line and then the closing summary, which is exactly what that run prints.
+
+## 0.5.118
+
+### Fixed: one failed write, two error lines, and the second one wrong about it
+
+`edf2csv wide.edf --info > desc.txt` onto a filesystem with no room:
+
+```
+error: Writing to stdout failed: ENOSPC: no space left on device, write
+error: Writing to stdout failed: 58900 of 58900 bytes did not reach the destination, which
+       stopped accepting them part way through.
+       What is there ends mid-row and should not be used. ... and nothing after it raised an
+       error because there was nothing after it.
+```
+
+Three of the second message's claims are false of what happened. Nothing was accepted, so the
+destination did not stop part way through. The file is empty, so nothing "is there" and nothing
+ends mid-row — and a description is a table, which has no rows to end mid-. And something after
+it did raise an error: the line printed directly above.
+
+The stdout audit exists for the one failure nothing else reports, a write that is accepted and
+silently truncated. When the stream itself has already errored there is nothing left for it to
+add, and it now says nothing. When it does speak and nothing landed at all, it says so rather
+than describing a short write.
+
+### Fixed: and then that failure exited 0
+
+With the audit silent the run exited 0 — the error printed, the file zero bytes, and success
+reported. The stdout listener sets the failing exit code, and the entry point assigned `main`'s
+0 straight over it; the audit's second error was the only thing that had been making the run
+fail. A code already set by a reported write failure now survives a run that returns 0.
+
+A closed pipe still exits 0: that path deliberately sets no code, which is what makes
+`--info | head` an ordinary thing to do rather than a failure.
+
 ## 0.5.117
 
 ### Fixed: the recipes page loaded a file the example recording never writes

package/dist/cli.js

@@ -1694,7 +1694,19 @@ const invokedDirectly = isMainModule();
 if (invokedDirectly) {
     main(process.argv.slice(2))
         .then((code) => {
-        process.exitCode = code;
+        /*
+          A write failure already reported is not erased by a run that thought it finished.
+  
+          The stdout listener above prints `Writing to stdout failed: ...` and sets EXIT_ERROR,
+          and assigning `code` over it put that back to 0 — so `--info > desc.txt` onto a full
+          filesystem printed the error, left a zero-byte file, and exited 0. It only looked
+          right because the stdout audit threw a second error on the way out, whose message was
+          about a short write that had not happened.
+  
+          A closed pipe deliberately sets no code (see ignoreBrokenPipe), so `--info | head`
+          still exits 0 through here.
+        */
+        process.exitCode = code === EXIT_OK ? (process.exitCode ?? EXIT_OK) : code;
     })
         .catch((error) => {
         process.stderr.write(`error: ${message(error)}\n`);