docs(ls): document the toString() override

No change to logic. This documents `shell.ls('-l')`'s `.toString()`
override. I noticed this feature was not documented. This string format
should not be depended on by programmatic usage, but it's useful to make
things more human readable.
This commit is contained in:
Nate Fischer 2022-01-15 12:29:57 -08:00 committed by Nate Fischer
parent b4daff5fd2
commit f45d256940
2 changed files with 16 additions and 8 deletions

View File

@ -430,10 +430,14 @@ Available options:
+ `-A`: all files (include files beginning with `.`, except for `.` and `..`)
+ `-L`: follow symlinks
+ `-d`: list directories themselves, not their contents
+ `-l`: list objects representing each file, each with fields containing `ls
-l` output fields. See
[`fs.Stats`](https://nodejs.org/api/fs.html#fs_class_fs_stats)
for more info
+ `-l`: provides more details for each file. Specifically, each file is
represented by a structured object with separate fields for file
metadata (see
[`fs.Stats`](https://nodejs.org/api/fs.html#fs_class_fs_stats)). The
return value also overrides `.toString()` to resemble `ls -l`'s
output format for human readability, but programmatic usage should
depend on the stable object format rather than the `.toString()`
representation.
Examples:

View File

@ -26,10 +26,14 @@ common.register('ls', _ls, {
//@ + `-A`: all files (include files beginning with `.`, except for `.` and `..`)
//@ + `-L`: follow symlinks
//@ + `-d`: list directories themselves, not their contents
//@ + `-l`: list objects representing each file, each with fields containing `ls
//@ -l` output fields. See
//@ [`fs.Stats`](https://nodejs.org/api/fs.html#fs_class_fs_stats)
//@ for more info
//@ + `-l`: provides more details for each file. Specifically, each file is
//@ represented by a structured object with separate fields for file
//@ metadata (see
//@ [`fs.Stats`](https://nodejs.org/api/fs.html#fs_class_fs_stats)). The
//@ return value also overrides `.toString()` to resemble `ls -l`'s
//@ output format for human readability, but programmatic usage should
//@ depend on the stable object format rather than the `.toString()`
//@ representation.
//@
//@ Examples:
//@