On Thu, 14 Apr 2022 21:42:51 -0500
Chibby Bromanson <chibby.bromanson_AT_eightbitmonster.com> wrote:
Dear Dorian,
> I am very impressed with the suckless software movement and I am doing
> my best to try to create my own tool that follows the philosophy. I
> still have a lot to learn with the C language but so far I am proud of
> the results. I would be greatful if someone would review my tool and
> consider it for inclusion in the list of tools that ROCK! :D
>
> The tool is for maintaining a list of descriptive tags on an extended
> file attribute. It plugs in nicely with fzf and other command line
> tools.
>
> http://github.com/bromanbro/taggins
>
> Thank you for your consideration.
thanks for reaching out! I am not a fan of xattrs, but they have their
place in the world and are a good vehicle for tagged file systems. This
space is not explored deeply enough, and some of my customers regularly
ask me if I know of a tagged fs solution that is easy to use for
non-technical people.
Regarding the code itself: As Hadrien already mentioned, autohell is
way overkill for what you're doing. In general, given xattrs are
non-portable, I would use a construct like
#ifdef __linux__
#include <sys/xattr.h>
#else
#error "system not supported"
#endif
and possibly create a "translation" layer of some sorts in a separate
compilation unit tag.c which handles all the unportable stuff.
tag.h would specify "general" functions (whose interfaces themselves are
POSIX compliant) like
int tag_add(...)
int tag_remove(...)
bool tag_is_set(..)
and all the ugly details would be "hidden" in tag.c, where you could
have a rough structure like
#ifdef __linux__
#include <sys/xattr.h>
#else
#error "system not supported"
#endif
int
tag_add(...)
{
...
#ifdef __linux__
...
#else
#error "system not supported"
#endif
...
}
If you, some day, decide to add extattr_ support (used in FreeBSD), you
simply add another case in the ifdef, but you won't need to change any
code outside of tag.c. As a crazy idea, you could also include a
fallback in the else-case where you create a dot-metafile in the
directory to store the attributes, but that's another matter.
Given the program's simplicity I wouldn't use separate src- and
man-folders, but that's a matter of taste.
I'd nuke AUTHORS (that's what LICENSE is for), COPYING (you already
have LICENSE), ChangeLog (put this stuff in README), Makefile.am,
Makefile.in, NEWS (no one cares), README.md (I'd just use README and
use markdown in there), compile, config.h.in, configure, configure.ac,
depcomp, install-sh, missing (for obvious reasons. Your tool can be
compiled with a 5-line-Makefile. If you don't know how, let me know and
I'll help you out).
With best regards
Laslo Hunhold
Received on Fri Apr 15 2022 - 11:53:54 CEST