Nice to read an older piece of clean C code once in a while. Gives me that cozy retro feel and fond childhood memories.
Beautifying the output sounds like a good idea, perhaps something like this should be an option of standard ls?
What strikes me is that the code (which is very idiomatic of C code) is very expressive at the function level, but most of it happens inside the few functions, and the function bodies are much less readable for those who don't write C ls clones all day. The main function is very long because it handles command line switches, that boilerplate could be moved to a function or library.
The file lc.1 (UNIX man pasge) is missing, as has already. been pointed out.
• simple/compact: single file
• small: 446 lines of C code
• flat/monolithic: lots of global variables, no separation between functionality and I/O, no separation between command and library API that does the core part of the work.
(Just posting what was on my mind, not my intention to attack this fine work!)
I think it’s fine. The code is clear enough and easy enough to maintain. There’s nothing wrong with a good top-down flow through a long function in my opinion. Especially when you’re dealing with a small, focused tool like this.
Thank you. In the dawn to f the unix wars, after giving up on Xenix, and getting a fast 386, someone loaned me a copy of the runtime - what a breath of fresh air. After a week, I ordered the full package. I remember some things it would do - like it snapped. Then documentation left something to be desired, so the company send me a disk of the updated documentation,and it's short comings were no longer a concern.
Apparently it impressed Dennis R. Enough to say it was the very best clone, and no, it did not infringe on the source code.
I remember one reviewer that couldn't make the Coherent copy of uucp to talk to another Unix machine's uucp, but that it worked fine between two Coherent machines and, therefore, joked it should be renamed cccp (as in Coherent to Coherent Copy Program)
If the author sees this: please copy/paste the manual in your README instead of including an image with text on it. You’ll help blind people and search engines.
Not author, but lc was posted on HN some years ago and at the time I was like "oh, I should really port over the original man page some day". After which I half did it, then forgot about it. I'm commenting here to commit myself to actually finishing that!
There's also one in this PR now :) Saying I'm going to do something is more likely to get it done than just thinking about it! https://github.com/gdm85/lc/pull/1/files
But, yes, that is the manual page I converted from (actually I grabbed it from the tarballs linked in the README - should be the same thing). My entire experience of troff would fit on the inside of a Rizla packet with some space to spare, but looking at the original I think it was using some special macro package that doesn't exist on modern systems. So I re-wrote it to use `-man` macros as best I could, but also included the original man page source for anyone that thinks they can do a better job in future.
Not to be confused with another lc, which is a highly configurable "multi-dimensional"[1] file lister focused on flexibility and configurability, written in Nim.
What's the point of JSON output anyway? UNIX filenames can contain arbitrary sequences of bytes except NUL and /, they can't be represented as JSON strings.
Categories are difference from what I expected as well, I was thinking file types.
This is really nice though. I do like that directories and files are separate. You could probably hack this a bit and give you directories, git repos and files. I know that a git repo is just a directory, with special files, but it's surprisingly often that I find myself wondering if a directory is a git repo.
if (dflag)
prtype(dirs, "Directories");
if (fflag)
prtype(files, "Files");
if (lflag)
prtype(links, "Symlinks");
if (cflag)
prtype(chars, "Character special files");
if (bflag)
prtype(blocks, "Block special files");
if (pflag)
prtype(pipes, "Pipes");
if (mflag)
prtype(mults, "Multiplexed files");
Nice to read an older piece of clean C code once in a while. Gives me that cozy retro feel and fond childhood memories.
Beautifying the output sounds like a good idea, perhaps something like this should be an option of standard ls?
What strikes me is that the code (which is very idiomatic of C code) is very expressive at the function level, but most of it happens inside the few functions, and the function bodies are much less readable for those who don't write C ls clones all day. The main function is very long because it handles command line switches, that boilerplate could be moved to a function or library.
The file lc.1 (UNIX man pasge) is missing, as has already. been pointed out.
• simple/compact: single file
• small: 446 lines of C code
• flat/monolithic: lots of global variables, no separation between functionality and I/O, no separation between command and library API that does the core part of the work.
(Just posting what was on my mind, not my intention to attack this fine work!)
I think it’s fine. The code is clear enough and easy enough to maintain. There’s nothing wrong with a good top-down flow through a long function in my opinion. Especially when you’re dealing with a small, focused tool like this.
I wouldn’t call it listed in columns when the order is row-major. Rather listed in rows.
BTW, one can download Coherent as a VM:
https://www.icl1900.co.uk/unix4fun/coherent/ftp/vms/
Additional Information:
https://www.icl1900.co.uk/unix4fun/coherent/
http://www.nesssoftware.com/home/mwc/
Thank you. In the dawn to f the unix wars, after giving up on Xenix, and getting a fast 386, someone loaned me a copy of the runtime - what a breath of fresh air. After a week, I ordered the full package. I remember some things it would do - like it snapped. Then documentation left something to be desired, so the company send me a disk of the updated documentation,and it's short comings were no longer a concern.
Apparently it impressed Dennis R. Enough to say it was the very best clone, and no, it did not infringe on the source code.
I remember one reviewer that couldn't make the Coherent copy of uucp to talk to another Unix machine's uucp, but that it worked fine between two Coherent machines and, therefore, joked it should be renamed cccp (as in Coherent to Coherent Copy Program)
If the author sees this: please copy/paste the manual in your README instead of including an image with text on it. You’ll help blind people and search engines.
Not author, but lc was posted on HN some years ago and at the time I was like "oh, I should really port over the original man page some day". After which I half did it, then forgot about it. I'm commenting here to commit myself to actually finishing that!
There's a man page here <https://github.com/gspu/Coherent/blob/a00b86ea22c66625cf1838...>
There's also one in this PR now :) Saying I'm going to do something is more likely to get it done than just thinking about it! https://github.com/gdm85/lc/pull/1/files
But, yes, that is the manual page I converted from (actually I grabbed it from the tarballs linked in the README - should be the same thing). My entire experience of troff would fit on the inside of a Rizla packet with some space to spare, but looking at the original I think it was using some special macro package that doesn't exist on modern systems. So I re-wrote it to use `-man` macros as best I could, but also included the original man page source for anyone that thinks they can do a better job in future.
Thank you for the PR!
<3
Not to be confused with another lc, which is a highly configurable "multi-dimensional"[1] file lister focused on flexibility and configurability, written in Nim.
https://github.com/c-blake/lc
Key features:
- Multi-level sorting by combinations of attributes like size, time, and file type, with user-defined precedence
- Configurable file kind sorting order
- Value-dependent coloring for file attributes such as timestamps, permissions, or sizes.
- Abbreviations: Automatically shorten filenames, user/group names or symlink targets.
- File type classification: Integrates libmagic for file type inspection.
- Hyperlink support
- Per-directory configs: custom behaviors for specific directories using local tweak files (.lc).
- Lightweight (~900 lines of code) with only author's CLI library "cligen" and Nim's stdlib as dependencies.
and more.
[1]: https://github.com/c-blake/lc#vector-typemulti-dimensionalit...
I was a Coherent User and lc was my goto file list.
Hacked pretty fast a version with json support, not pretty but just as a concept: https://github.com/Rucadi/lc
I give you the file called ":
What's the point of JSON output anyway? UNIX filenames can contain arbitrary sequences of bytes except NUL and /, they can't be represented as JSON strings.
No colorful text, no emojis, no Unicode decorations. Nice.
No rust either?
The day is still young. Wait for it, there'll be one (or 3) soon.
With 865 dependencies pulled in by cargo :-)
is there a leftpad crate?
Next we gotta jettison capital letters to really trim the cruft
Old news, now it is all about RIIZ.
The categories being "files" and "directories"? So just two categories?
Categories are difference from what I expected as well, I was thinking file types.
This is really nice though. I do like that directories and files are separate. You could probably hack this a bit and give you directories, git repos and files. I know that a git repo is just a directory, with special files, but it's surprisingly often that I find myself wondering if a directory is a git repo.
if (dflag) prtype(dirs, "Directories"); if (fflag) prtype(files, "Files"); if (lflag) prtype(links, "Symlinks"); if (cflag) prtype(chars, "Character special files"); if (bflag) prtype(blocks, "Block special files"); if (pflag) prtype(pipes, "Pipes"); if (mflag) prtype(mults, "Multiplexed files");