electrux / ls_extended Goto Github PK

First of all, thank you for writing ls_extended. It makes the ls output both nicer to look at and more efficient to work with!

This is ls_extended compared to regular ls

Would it be possible to have less space around the username and the group? And also around the hard link count. When working in a split screen I often get files wrapping to the next line when they would easily have fit on one line had the output just been a bit more compact (more like the regular ls output)

Not an issue just a question. Instead of building this in the repo's bin dir. Is there a way to make this install it in the actual /bin. dir? Am I able to just move the ls_extended dir that was generated into /bin or does it need more work and configuration for that to work.

Thanks for making this project! I just found a little bug:

I'm using termite as my terminal.

$ uname -a
Linux 505cf5a8c892 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
$ ./ls_extended
 ls_extended

It will be memory leak. sink is in src/vec.c:37.

The problem is when i go to if( flags & OPT_V )... else{}, the else is only return not free, so that memory leak.
Maybe the solution is add vec_destroy( & locs ); in main.c:54
thank you!

Issue:

A symlink that points to itself causes a seg fault. I had this occur while changing some dotfile configurations.

Way to reproduce:

Create a file, create a symlink to that file, delete the file and rename the symlink to the name of the original file, keeping it in the original directory. This creates a symlink that points to itself.

Obviously this isn't really that big of a deal considering this shouldn't happen in the first place. But it should probably be accounted for so that you can be aware that you even have one in the first place.

Some of the hard-coded unicode codepoints have changed or were removed (eg. \uf7a3 aka. the github icon). These should be replaced with working codepoints.

Google Drive (now Google Backup and Sync) creates files named "Icon\r" in each folder that is synced. When displayed via ls, it simply lists "Icon?". However, when using ls_extended, it outputs a "\r", causing rather severe alignment/spacing issues as you might imagine, since the cursor goes to the beginning of the line. I worked around the issue by adding a strncmp check for "Icon\r" files and ignoring them in this line, but that is a stopgap measure at best. You may wish to consider simply stripping CR characters or, as ls does, outputting '?' instead.

If the group name length one is <8, another one is >8. The tab alignment is not working, it will output like:

 -rw-r-----     1       qqldd      self     54B     May 26 06:53      configs_dir.sh
 drwxr-x---     2       qqldd      longnamegroup    4096B   Jun 12 18:30      crontab

This looks really fantastic! Just installed today... Really a brilliant idea!

Curious if you've considered supporting some of the GNU ls sort options?

Personally the ones I use all the time are:

lsdate=ls -tr # sort by modified time, newest last (since -r reverses list)
lssize=ls -Sr # sort by size, largest last
lstype=ls -X # sort by extension... would be cooler than ever with icons!

Reference:

       -t     sort by modification time, newest first
       -S     sort by file size, largest first
       -X     sort alphabetically by entry extension
       -r, --reverse
              reverse order while sorting

Please add support for ISO 8601 date format. In regular ls, this is enabled with --time-style=long-iso. Below I have pasted an example what happens currently with regular ls and ls_extended.

~/test
❯ /usr/bin/ls -l --time-style=long-iso
total 0
-rw-r--r-- 1 reekymarko users 0 2018-09-30 17:32 file1
-rw-r--r-- 1 reekymarko users 0 2018-09-30 17:32 file2

~/test
❯ /usr/bin/ls_extended -l --time-style=long-iso
 4063667     -rw-r--r--		1	reekymarko	users	0B	Sep 30 15:32	 file1
 4063668     -rw-r--r--		1	reekymarko	users	0B	Sep 30 15:32	 file2

I tried ls_extended but it seems that it doesn't respect my ~/.dircolors.

Am I missing something or is this not implemented ?

Would it be difficult to implement ?

Screenshot:
https://i.imgur.com/TNpbWJC.png

There are nine bugfixes since version 1.0.0. I think you should consider making another release.

I have two problems:

1. ls_extended file.* returns " "Unable to open directory: file.txt/"
2. ls_extended * returns the last file from ls *

Ubuntu 20.04 LTS, ./build.sh:

/usr/bin/ld: buildfiles/src/ls.c.o: in function `get_stats':
ls.c:(.text+0x5c5): undefined reference to `dirname_r'

What's the idea behind assigning .json files ﬥ U+FB25 HEBREW LETTER WIDE LAMED?

FWIW the lsd project uses  U+E60B.

EDIT: I see at the Nerd Fonts site that they indeed use fb25 as nf-mdi-json as well as e60b as nf-seti-json. I have a preference for the latter as it's in the private use area, while the former is part of an alphabet.

But I understand most users will have nerd-patched fonts, and get it if this is rejected if fb25 is generally preferred.

ls_extended calls gcvt at src/core.c:120. On some OS's (FreeBSD for instance) gcvt is unavailable. Is there any reason gcvt is used over snprintf? I have a fork with the change made, if this is something that would be considered for merging?

It would be nice to have a homebrew formula for ls_extended

Pretty much just what the title says. --help is more commonly used as the "help message" flag than help. --help is also less likely to be the name of an existing file or folder that someone could be trying to call ls on.

I've noticed an unexpected behavior with the ls_extended binary when it's copied to /usr/local/bin/ls using the sudo cp command. Instead of behaving like the standard ls command, it outputs the contents of a folder as if it was invoked with the -l option.

Steps to Reproduce:

Download and compile the ls_extended binary.
Copy the ls_extended binary to /usr/local/bin/ls using the following command:

sudo cp ls_extended /usr/local/bin/ls

Navigate to a directory with subdirectories and files.
Run the ls command in the directory.
Observe the output, which is different from the expected behavior of the standard ls command.

Expected Behavior:
The ls command, when invoked after copying ls_extended to /usr/local/bin/ls, should display a basic list view of files and directories, similar to the standard ls command, without the -l option.

Actual Behavior:
The ls command, after copying ls_extended to /usr/local/bin/ls, is displaying the contents of a folder as if it was invoked with the -l option, which includes detailed information about files and directories.

Additional Information:

ls_extended Version:  1.0
Operating System: linux mint

Screenshots/Additional Context:

Note: Please let me know if there is any specific configuration or behavior-related information that would help diagnose and resolve this issue.

Sometimes a single file is broken up into two lines

Can I change text colors somehow? Is there a config for editing?