[dev] [sbase] find and xargs different results than busybox

[andremw]

Hello friends.
I always used busybox but now I decided to use sbase because of the simplicity and lightweight.
I had a script to fix /home/user files and directories permissions that always worked on busybox but fails on sbase.
I wonder if the programs in sbase have a bug or if my commands aren't POSIX. Any insight in this is well regarded.
Thank you.

The commands-
-find /home/user -type d -print0 | xargs -0 chmod 0775
-find /home/user -type f -print0 | xargs -0 chmod 0664

In busybox they work, in sbase they return-
-find: paths must precede expression: -print0
-usage: xargs [-rtx] [-E eofstr] [-n num] [-s num] [cmd [arg ...]]


Thank you.

[Quentin Rameau]

Post by andremw
Hello friends.

Hello Andrew,

Post by andremw
I always used busybox but now I decided to use sbase because of the simplicity and lightweight.

Nice!

Post by andremw
I had a script to fix /home/user files and directories permissions that always worked on busybox but fails on sbase.
I wonder if the programs in sbase have a bug or if my commands aren't POSIX. Any insight in this is well regarded.
Thank you.
The commands-
-find /home/user -type d -print0 | xargs -0 chmod 0775
-find /home/user -type f -print0 | xargs -0 chmod 0664

Well, first you could have a look at the sbase find manpage.
Then indeed, check out the POSIX specs for it (also in a few cases,
sbase utils can support extension if they can be done in a portable
manner).

Post by andremw
In busybox they work, in sbase they return-
-find: paths must precede expression: -print0

The error message could, maybe, be improved, but that's already a hint
to lookup in the manpage.

Post by andremw
-usage: xargs [-rtx] [-E eofstr] [-n num] [-s num] [cmd [arg ...]]

No stdin data.

[Evan Gates]

Post by andremw
-find /home/user -type d -print0 | xargs -0 chmod 0775
-find /home/user -type f -print0 | xargs -0 chmod 0664
In busybox they work, in sbase they return-
-find: paths must precede expression: -print0
-usage: xargs [-rtx] [-E eofstr] [-n num] [-s num] [cmd [arg ...]]

find -print0 is not specified by POSIX. If you want to print nul
separated data use:

find ... -exec printf %s\\0 {} +

But that's normally useless as xargs -0 is also not specified by
POSIX. The solution is to just use find's -exec. The two commands
would be:

find /home/user -type -d -exec chmod 0775 {} +
find /home/user -type f -exec chmod 0664 {} +

[Eric Pruitt]

Post by Evan Gates
find -print0 is not specified by POSIX. If you want to print nul

The suckless tools don't strictly follow POSIX. For example, sbase mv(1)
and cp(1) don't support "-i". Furthermore it's pretty portable; find(1)
on OpenBSD, FreeBSD, macOS and GNU find(1) all support using NUL bytes.
It's the only sane way to securely support any legal filename.

Eric

[Markus Wichmann]

Post by Eric Pruitt
The suckless tools don't strictly follow POSIX. For example, sbase mv(1)
and cp(1) don't support "-i". Furthermore it's pretty portable; find(1)
on OpenBSD, FreeBSD, macOS and GNU find(1) all support using NUL bytes.
It's the only sane way to securely support any legal filename.
Eric

And that's where you're wrong. "find | xargs" is wrong for the same reason
"sudo su" is wrong, for the same reason "cat singlefile | whatever" is
wrong: You're doing it wrong. In your case "find -exec" does everything
you want. It also supports all possible file names.

Ciao,
Markus

[Eric Pruitt]

Post by Markus Wichmann
And that's where you're wrong. "find | xargs" is wrong for the same reason
"sudo su" is wrong, for the same reason "cat singlefile | whatever" is
wrong: You're doing it wrong. In your case "find -exec" does everything
you want. It also supports all possible file names.

I didn't provide a case, but here's one I have mind: what if you only
want to run commands if "find" finishes with an exit status of 0? With
find -print0 and xargs -0, it'd look like this:

set -e
find ... -print0 > results
xargs -0 ... < results

[Cág]

If you take a look at README (https://git.suckless.org/sbase/tree/README),
you'll find out completeness of the programs and missing arguments; out
of all I only wonder why multi-column output of ls(1) is intentionally
left out. On Plan 9 it is one-column, too, though.
caóc

[Markus Wichmann]

This post might be inappropriate. Click to display it.

[Cág]

Post by Markus Wichmann
Because ls's job is to list files. Not to columnate output. There's
another tool for that.

Makes sense; there's cols(1) for that.

Post by Markus Wichmann
Unfortunately, GNU ls is capable of outputting color codes, but BSD
column is not capable of understanding them. I tried to write something
like this myself, once, and I wonder what's the easiest way to find out
the width a string will take up on a terminal. Because that's the info
you need to columnate the output properly, and short of implementing all
possible terminal control strings myself again, I don't know how to do
this. wcwidth() is of limited utility in this quest, as control codes
consist of multiple characters of which most do take up space if on
their own, but don't in this sequence.

I see no need in colors in terminal except maybe one-two programs; with
BusyBox I have to alias ls to "ls --color=never", because by default it
shows color, a behavior copied from gahnoo.

--
caóc