edf2csv 0.5.116 → 0.5.118

package/CHANGELOG.md

@@ -3,6 +3,78 @@
 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.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
+
+recipes runs `edf2csv sleep-study.edf --out ./sleep_csv`, shows an `ls` of the result, and then
+reads it fourteen times over — pandas, R, data.table, MATLAB, DuckDB, the chunked reader, the
+`merge_asof` recipe. Every one of them opened `sleep_csv/signals_256hz.csv`.
+
+That recording has no 256 Hz channel. It has three at 100 Hz, one at 10 Hz and one at 1 Hz, and
+converts into six files:
+
+```text
+annotations.csv
+channels.csv
+metadata.json
+signals_100hz.csv
+signals_10hz.csv
+signals_1hz.csv
+```
+
+The `ls` block listed four, one of them a file the run does not write and three of them missing.
+Every snippet on the page after it was a `FileNotFoundError` on its first line.
+
+The channel names went with it: the snippets print an `ECG` column, which belongs to a different
+recording — this one's third 100 Hz channel is `EOG horizontal`. The `--info` table a hundred
+lines above them has listed the real channels and the real file names all along.
+
+faq's answer to "why several signals files" laid the same recording out as `signals_256hz.csv`,
+`signals_128hz.csv` and `signals_1hz.csv`, and its two loader snippets and its digital-code
+recipe read the 256 Hz file.
+
+Corrected against a conversion: file names, channel names, the sample values and times in the
+outputs shown, the wall-clock example's timestamps, the `channels.csv` listing, and the count of
+interpolated rows in the `merge_asof` note (2,880,000 at 100 Hz, not 7,372,800 at 256 Hz).
+
+A test converts one second of the fixture the example recording is built from and holds every
+path under that output directory, and the `ls` block itself, to what the run writes.
+
 ## 0.5.116
 
 ### Fixed: a recording it is not allowed to read came back as a raw Node error

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`);