First, thanks for your efforts on this project; it's been a vital tool for Linux installations.
-0: If feeding the output of lsattr into another program, there are some difficulties. Any filenames containing newlines mess up the output. Many programs (find, xargs, etc.) allow optional NUL-termination when a -0 flag is supplied. I suggest that lsattr could also offer this option. This would prevent filenames with newlines from mangling the output. Looking at lsattr.c, it seems like this would not be a complex change.
I can submit a patch, but I figured I would wait for feedback from the maintainers of the project first. Thanks for your attention.
We could add the an option to add NUL termination, but I'm not sure it would really help all that much. Lsattr really wasn't designed to be easily parseable by a program. And certainly when we add support for new flags, it will likely break programs that aren't expecting the width of the flags field to change. If were going to add this support, which was designed to be used by a perl or python script, I'd probably change it to return the flags as a hex value, and expect the script to interpret the hex value to pull out the necessary flags directly.
Well, I found one complication. When doing "lsattr -R", there are headers for the various directories. As the headers differ in structure from the normal "-------------- filename" format, they would be more difficult for another tool to parse, and not as clearly useful as when output is presented to a human. I would be inclined to remove these headers when -0 is enabled.
[just saw your reply after I sent my auto-reply]
Sure, that makes sense; if you're intending lsattr for human consumption, then this is the wrong place for it.
Actually, it may be better for me anyway to just call fgetflags() directly from my program. I can do that with the current distribution (by just including e2p/e2p.h and linking with -le2p).
I see that the e2p functions don't have man pages yet; if you'd like someone to run through those functions and create man pages, I could do that. Otherwise, I'll just leave it at "thanks for the project".
Either man pages or texinfo documentation. I have partial library documentation for libext2 in doc/libext2fs.texinfo. I've always meant to expand on it, but I've never gotten around to it. Having documentation for libe2p and/or blkid, and expanded documentation for libext2fs would be greatly appreciated. If you are interested in writing documentation, either in man page or texinfo format, contributions would definitely be welcomed.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.