Re: [Toybox] Fwd: hexedit uses VT-420 scroll ctrl sequences which dont work on tty1

[Robert Thompson]

That all works in screen, at least to some extent. Years ago I discovered I
could write a script and connect its stdin to the stdout of whatever was in
the screen, and vice versa. I think what led me to the discovery was
someone's description of how to do zmodem over SSH to a network switch (it
treated SSH like it was the serial console, expected zmodem for firmware
updates, and made no attempt to support scp).

For that matter, screen can be a pretty good substitute for picocom (and
it's commonly available everywhere). I believe that tmux removed direct
serial (and raw pty?) support in an attempt to create a more maintainable
codebase.


On Wed, Sep 25, 2019, 18:56 David Seikel 
wrote:

> On Wed, 25 Sep 2019 12:24:13 -0500 Rob Landley said :
> > On 9/24/19 1:18 AM, Jarno Mäkipää wrote:
> > > Hi
> > >
> > > I now tested to run hexedit in tmux: downscroll works but upscroll
> > > does not... Well we might say its tmux fault, but lots of people
> > > use tmux nowadays. And this behavior seemed to be same in
> > > framebuffer console and xterms...
> >
> > I have a todo item to write a screen for toybox. I'll make sure this
> > works there. If you want to submit a bug report to the old one, have
> > at.
>
> Would writing a tmux be a better option than a screen?  I prefer it for
> several reasons, the major one being that I can script reading and
> writing text to what ever command is running inside tmux (in my case
> OpenSim consoles for cron'ed backups).  Mouse support is handy to.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] CTRL-T in freebsd shell...

[Robert Thompson]

When you need CTRL-\, you *really* need it...


On Sun, May 19, 2019, 04:35 Rob Landley  Would anyone aware of freebsd's CTRL-T want to weigh in on this thread?
>
>   https://twitter.com/freebsdfrau/status/1128017757734297600
>
> I can remap ctrl-\ to ctrl-t and have SIGQUIT produce statistics, but the
> _obvious_ side effect of that is apps having to block SIGQUIT to use
> CTRL-T,
> which seems bad...
>
> I don't think I can get ctrl-T to produce SIGINFO without a kernel
> modification.
>
> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] gmail unsubscribed everyone from the list again.

[Robert Thompson]

For what it's worth,

http://www.gnu.org/software/mailman/mailman-admin/node25.html

It's been several years since I had to deal with this kind of thing,
but the behavior we're seeing is similar to a case I had to
troubleshoot in the past where the bounce-processing was configured to
be too aggressive. This caused subtle trouble when some sites started
implementing greylisting and rate-limited acceptance. I believe that
gmail does both nowadays...

I ended up having to significantly increase the threshold as well as
set the stale period very low. Some of the behavior I saw didn't match
the documentation, and the final values that fixed the problem should
not have been very useful as per the documentation, but the problem
went away :shrug:


On 2/9/19, dmccunney  wrote:
> On Sat, Feb 9, 2019 at 3:49 PM David Seikel
>  wrote:
>>
>> > I fixed it all up via the web gui when gmail did this last week, and
>> > I just fixed it up again after yesterday's mass-bouncing, but I'm
>> > kind of tired of it.
>> >
>> > As far as I can tell, other mailing lists are coming to a "gmail is
>> > too dysfunctional to use with mailing lists" consensus:
>>
>> I've been saying that here for some time.  Everybody just move off gmail
>> and be done with it.  My non gmail address wasn't bounced off the list.
>> Gmail is bad, m'kay.  Protonmail.com works OK if you want a web based
>> alternative.
>
> Gmail works fine here for every *other* mailing list I'm on, including
> a couple I created and maintain as Google Groups.
>
> The biggest mailing list problems I encounter are with folks
> subscribed via AOL or Yahoo addresses.  Those sites turned on
> provisions of the DKIP specification that specify that headers may not
> be *changed* en route.  This breaks mailing lists, as mailing list
> managers must diddle headers as part of what they do.  What happens
> depends on the servers that get the list mail.  Some will discard it
> undelivered as spam and not mention they have.  Some will accept and
> deliver it, but label it spam (Gmail does this.)  I've told folks on
> various lists using AOL or Yahoo addresses they have three choices:
>
> Stay subscribed to the list from their AOL or Yahoo address, but be
> aware that other list members may never see their posts
> Drop off the list
> Find another email provider.
>
> I don't know what Gmail's allergy to the Toybox list is, but I don't
> think Gmail is the problem.
>
> (I have a Proton mail account.  Handy for the privacy obsessed, but
> way too slow for volume traffic here.)
> __
> Dennis
> (Who was *delighted* to shift to Gmail, drop MS Outlook as email
> client, and download mail locally via POP)
> https://plus.google.com/u/0/105128793974319004519
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Github "failed to load latest commit information"?

[Robert Thompson]

I've seen that when javascript is blocked, or partially blocked. I
think I've seen it once when I was behind a non-transparent
non-CONNECT proxy, but that was a while ago and I can't verify.

It's not new behavior. I've been seeing this for at least two years,
unless I allow *all* javascript on github and its child contexts.

I usually restrict javascript by default and allow only the minimum
necessary for a page to function, because that lets my old junker
netbook get 6 hours of battery life instead of 2.



On 6/30/18, enh  wrote:
> It's working for me.
>
> On Sat, Jun 30, 2018, 07:29 Rob Landley  wrote:
>
>> https://github.com/landley/toybox/tree/master/toys is giving me an error,
>> but
>> clicking on the error message doesn't give details.
>>
>> Microsoft hasn't even owned it a month yet, this is silly. The commit log
>> seems
>> reasonable...?
>>
>> Sigh. I break everything.
>>
>> Rob
>> ___
>> Toybox mailing list
>> Toybox@lists.landley.net
>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>>
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] RFC: "ps -o ?", "logger -p ?", "kill -s ?"

[Robert Thompson]

It's nice where the "what do I put here?" and the "that particular
argument isn't supported in this version" logic cases can be folded
together.  Just list valid choices for that argument, then terminates
unsuccessfully (non-zero error code, but without the normal "I didn't
understand you" error messages.

It is nice to be able to differentiate between known-unsupported
arguments and unrecognized arguments. '--foo: "x" is not supported in
this version', vs "--foo: unknown argument 'x'. Valid choices are a,
b, c, bar."

As a nice side effect,  the code doesn't need to recognize a special
list-options argument...





On 2/20/18, enh  wrote:
> wasn't that the whole reason behind adding the suggestion to the
> syntax error message?
>
> ps: Missing argument to -o (see "ps --help")
>
> i think the only real problem is the old bug where commands like top
> don't show the -o/-O help from ps. (a quick workaround would be to
> mention the "see also" in the top help.)
>
>
> On Tue, Feb 20, 2018 at 10:43 AM, Rob Landley  wrote:
>>
>>
>> On 02/20/2018 12:15 PM, Rob Landley wrote:
>>> A lot of commands take a list of possible inputs to one of their options,
>>> and
>>> there should be a way to query "what are the inputs". The way qemu does
>>> it is to
>>> let you supply ? as the input (ala "qemu-system-i386 -M ?")
>>>
>>> The problem is ? is a shell wildcard so you have to quote it. Otherwise
>>> it works
>>> _almost_ all the time, and then barfs if you have a single character
>>> filename in
>>> your current directory because the shell swapped it out before running
>>> your command.
>>>
>>> Is there an obvious better api for this?
>>>
>>> Advantages of the qemu approach are A) a certain number of people out
>>> there are
>>> already familiar with this, B) if you see "ps -o ?" even once it's pretty
>>> easy
>>> to guess/remember what it does. Much more so than say "ps -o -".
>>> Disadvantage is
>>> shell wildcard...
>>>
>>> Hmmm...
>>
>> Ah, qemu seems to have noticed the wildcard problem, and changed their
>> recommendation:
>>
>>   $ qemu-system-i386 -M x
>>   qemu-system-i386: -M x: unsupported machine type
>>   Use -machine help to list supported machines
>>
>> Ok, I suppose the magic name "help" is reasonable...?
>>
>> (I could also output the list for any unknown type, but there should be an
>> error
>> message at the top, and then it's not "for i in $(ps -o helo)"; do az $i;
>> done"
>> scriptable.)
>>
>> (One thing I've wondered about is where to _document_ this, and the error
>> message telling you how to get help is the obvious place...)
>>
>> Rob
>> ___
>> Toybox mailing list
>> Toybox@lists.landley.net
>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Numeric values in dd operands

[Robert Thompson]

I've seen a fair number of scripts that use printf's ability to
interpret hex and octal arguments. This is often combined with
printf's ability to format outputs into decimal, octal, or hex, to
make a convenient base-shifter. For this discussion, it's the argument
conversion, not the formatting that's relevant...

Working from memory, I've seen patterns such as those below, often in
$() (or ` `) expansions. In some cases, the converted number was
roundtripped during the lifetime of the script.


printf "%u\n" 0377
255
(I've seen this one using both the "unsigned integer" and the various
printf(3) integer formatters)


printf "%o\n" 0x1b
33

printf "%#o\n" 0x1b
033

printf "%x\n" 77
4d

printf "0x%x\n" 77
0x4d

printf "%#x\n" 77
0x4d




On 2/20/18, enh  wrote:
> On Tue, Feb 20, 2018 at 9:57 AM, Rob Landley  wrote:
>> On 02/20/2018 11:32 AM, enh wrote:
>>> On Tue, Feb 20, 2018 at 9:28 AM, Rob Landley  wrote:
 A real user piped up and said their existing script doesn't work with my
 tool.
 That feedback is of interest to me.
>>>
>>> and as the person who set us down the strtol path
>>> (https://github.com/landley/toybox/commit/d5088a059649daf34e729995bb3daa3eb64fa432#diff-ce001a87e82f850a38fd93183e12b417),
>>> the original request i had was just for hex. like you say, no-one's
>>> used octal (on purpose) for anything other than mode for decades now.
>>
>> I'm tempted to have atolx() skip leading zeroes, and then base 16 if the
>> first
>> character is an x and base 10 otherwise. Except supporting the - basically
>> means
>> open coding the sucker...
>>
>> Anyway, my _real_ question is, if I'm yanking octal from dd= should I yank
>> it
>> from everywhere? I still think it's useful for "printf %d 0123" to be able
>> to
>> cope with it (especially since "printf %o 668" prints 1234). And maybe
>> $((0123))
>> needs it too?
>>
>> No clue where to draw the line on this one. Hmmm...
>
> you could make it opt-in and add octal support to places where its
> absence is actually noticed.
>
>> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] making ./configure executable.

[Robert Thompson]

Yeah, I ran into some similar issues years ago...  In my case,  I got
burned into learning not to assume that bash (or any other shell) is
correct, or even necessarily *self* consistent(even on linux), so I
tend to reflexively do differential checks. It's a very small amount
of effort in the normal case, but months of project time and a major
missed deadline tend to leave a bit of a scar :)

there was a "posix, we swear" vendor /bin/sh, a classic /bin/bash, a
"new and sexy" /bin/bash, and the same version/same configuration
/bin/bash running on a different hardware/os...

We wasted months assuming that the newer bash was most likely correct
(it was a heisenbug, both rare and inconsistent). In that case, turned
out that the posix sh was technically correct and consistent, and
*all* of the bashes exhibited *different* incompatible heisenbugs. And
they tended to show up only about a day into a massive
un-checkpointable processing run...

that eval *still* smarts, and worse, it was supposedly-legacy crap
that we were just supposed to "update a bit" (it had always been doing
this, we were just the first people who noticed)...



On 2/5/18, Rob Landley <r...@landley.net> wrote:
> On 02/05/2018 04:01 PM, Robert Thompson wrote:
>> It seems that the single-equals is POSIX, while the double-equals is a
>> bash extension that at one point bash preferred and extended the match
>> behavior of.
>>
>> But, the bash manpage now documents double-equals  (when in the
>> context of the builtin test or its '[' alias) as equivalent to
>> single-equals.
>
> I researched all this crud at one point, but it was a few years ago now. :)
>
>> The manpage notes that when using test (rather than '['), one should
>> always use single-equals, due to POSIX compatibility issues, in case
>> the script gets run by a shell without a builtin test.
>>
>> Bash has another extended test, '[[', which does significantly
>> different, and expanded, things, but its behavior was inconsistent
>> across bash versions the last time it was relevant to my work.
>>
>> Apparently bash's interpretation of single-equals isn't always exactly
>> POSIX-standard, depending on which bash settings are in effect. A
>> quick skim shows that it may or may not be case-insensitive, may or
>> may not be glob-active (older version), *is* glob-active (newer
>> versions, with caveats?)...
>>
>> dash's behavior isn't saying "unknown operator '['". It's saying
>> "builtin-test-via-left-square-bracket: unknown operator '=='". I think
>> it's just phrasing it really poorly due to overly simplistic
>> backtracking in its parser (most recent symbol being assumed to be the
>> cause of the error, thus printed).
>
> Dash is crap. The switch to dash was because Ubuntu wanted to run its
> init scripts faster and thought changing all the init scripts to start
> with #!/bin/dash was too intrusive a change. No really:
>
>   https://wiki.ubuntu.com/DashAsBinSh
>
> This broke (among other things) the Linux kernel build. (Bash was the
> first program Linux ever ran, Linus extended his term program to run
> bash specifically. /bin/sh being bash was the one thing all Linux
> distros agreed on, until Ubuntu did a stupid.)
>
> Then, of course, the redirect didn't speed init up enough so they went
> down the parallelizing route and created "upstart", but didn't back out
> the /bin/sh change because that would be admitting they made a mistake.
> (They did relent enough to change the default so user accounts would
> have bash as their default shell in /etc/passwd.)
>
> Yes, it is a pet peeve of mine. :)
>
> Rob
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] making ./configure executable.

[Robert Thompson]

It seems that the single-equals is POSIX, while the double-equals is a
bash extension that at one point bash preferred and extended the match
behavior of.

But, the bash manpage now documents double-equals  (when in the
context of the builtin test or its '[' alias) as equivalent to
single-equals.

The manpage notes that when using test (rather than '['), one should
always use single-equals, due to POSIX compatibility issues, in case
the script gets run by a shell without a builtin test.

Bash has another extended test, '[[', which does significantly
different, and expanded, things, but its behavior was inconsistent
across bash versions the last time it was relevant to my work.

Apparently bash's interpretation of single-equals isn't always exactly
POSIX-standard, depending on which bash settings are in effect. A
quick skim shows that it may or may not be case-insensitive, may or
may not be glob-active (older version), *is* glob-active (newer
versions, with caveats?)...

dash's behavior isn't saying "unknown operator '['". It's saying
"builtin-test-via-left-square-bracket: unknown operator '=='". I think
it's just phrasing it really poorly due to overly simplistic
backtracking in its parser (most recent symbol being assumed to be the
cause of the error, thus printed).



On 2/5/18, Ryan Prichard  wrote:
> FWIW: I think the problem is the double-equals operator:
>
> $ /bin/dash -c 'if [ x = x ]; then echo foo; fi'
> foo
>
> $ /bin/dash -c 'if [ x == x ]; then echo foo; fi'
> /bin/dash: 1: [: x: unexpected operator
>
> $ /bin/dash -c 'if /usr/bin/[ x == x ]; then echo foo; fi'
> foo
>
> POSIX hasn't specified ==. I'm guessing it's strictly equivalent to =?
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
>
> -Ryan
>
>
> On Sun, Feb 4, 2018 at 6:11 PM, Rob Landley  wrote:
>
>> I tried adding this to configure:
>>
>> if [ "$(basename "$0")" == configure ]
>> then
>>   echo "This file is just a persistent place to set environment
>> variables."
>>   echo "You probably want to run 'make defconfig'."
>>   echo "Type 'make help' for more options, or see the README."
>>   exit 1
>> fi
>>
>> But if your #!/bin/sh points to the Defective Annoying SHell it
>> goes "unexpected operator [" EVEN THOUGH "[" IS IN THE $PATH,
>> and I'm just not going there.
>>
>> So I've put #!/bin/bash at the top, set the executable bit, and
>> I'm keeping the complaint to one line and running "make defconfig"
>> anyway on the theory making it easier to use is better than trying
>> to educating people with a pop-up window error.
>>
>> Rob
>> ___
>> Toybox mailing list
>> Toybox@lists.landley.net
>> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>>
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[Robert Thompson]

When you get back to this, probably the two most useful places for seeing
how much existing tls code is required for ktls would be

https://github.com/ktls/af_ktls-tool/blob/master/client.c
https://github.com/ktls/af_ktls-tool/blob/master/xlibgnutls.c

The af_ktls-tool contains a bunch of testing noise, but also contains a
test client. The test client (starting around client.c line 1096) calls the
gnutls-based initiator (in xlibgnutls) then uses the ktls feature with the
gnutls-initiated session info.

It really looks like using ktls will depend on a full openssl or gnutls
library. Also, at the moment, ktls only implements one crypto suite (AES
GCM), so a client using ktls can't interoperate with all webservers. (on
the server side it matters less because the server-operator can choose only
to use AES GCM, and all clients will have to support that).




On Tue, Sep 5, 2017 at 5:33 AM, Rob Landley <r...@landley.net> wrote:

> On 09/04/2017 08:22 PM, Robert Thompson wrote:
> > From the toybox point of view, wouldn't this introduce direct link
> > dependency on ssl/tls libraries?
>
> There's already an optional dependency to accelerate hash calculations
> (CONFIG_TOYBOX_LIBCRYPTO), and another to accelerate zlib, so I'm ok
> with having that as an optional dependency.
>
> Having functionality you can _only_ get by linking that in is a much
> bigger ask. I want a self-contained system bootstrap build and/or
> hermetic build with minimal dependencies.
>
> So ideally I'd want the part of tls negotiation the kernel doesn't do
> implemented in toybox code, but I dunno how much that is yet...
>
> > If that's acceptable, the ktls stuff looks like a simple addition (on
> > top of base in-toybox tls) with potential performance improvements, once
> > the code settles down.
>
> Another thing is this adds a kernel version dependency, so I'd want a
> compile time probe for "is support there in this build environment"
> because http://landley.net/toybox/faq.html#support_horizon
>
> That said, my plan to spend the evening grinding on the toybox todo list
> seamlessly transitioned into hours analyzing GPS code and traces trying
> to figure out where the race condition is in the response to the
> correlator output (answer: there's two _different_ problems), so... :P
>
> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [RFC] ktls is in 4.13.

[Robert Thompson]

>From the toybox point of view, wouldn't this introduce direct link
dependency on ssl/tls libraries?

If that's acceptable, the ktls stuff looks like a simple addition (on top
of base in-toybox tls) with potential performance improvements, once the
code settles down.


On Sun, Sep 3, 2017 at 11:12 PM, Rob Landley  wrote:

> The kernel just merged "ssl renamed after thread local storage" support:
>
>   vpaper: https://netdevconf.org/1.2/papers/ktls.pdf
>   sample code: https://github.com/ktls/af_ktls
>
> It's basic https plumbing in the kernel, but doesn't do the handshake or
> renegotiation. What I'm wondering is would this be a better thing to try
> to plug into than the openssl command line utility?
>
> Worth bothering with?
>
> Rob
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] dd tests for transaction size?

[Robert Thompson]

It's pretty heavily used in combination with noerror. I can personally
attest to its usefulness when working with both damaged optical media and
spinning rust (with the correct blocksize in each case).

Each block read either contains blocksize data bytes or blocksize null
bytes, so that the source and destination still have matching offsets.

Incidentally, I've seen this used to progressively recover all readable
sectors on a damaged hard disk. Use a large
multiple-of-hardware-sector-size blocksize to start. The destination file
will retain (large) holes wherever there are bad blocks. searching for
aligned blocks of nulls will give you lists of offsets to seek and skip to
to retry with the smaller blocksize.

>From what I've seen, if a blocksized read overlaps with a bad sector, once
the kernel gives up on the sector, it fails the read without attempting any
further sectors. Since (before the days of widespread block-remapping)
sector failures often come in clusters, and avoiding reading bad sectors
can improve the odds of getting all the not-yet-bad sectors, you can play
iterative blocksize games to delay repeated risky reads until after most of
the good data is recovered.

I *have* seen this used with non-blockdevices, although at the moment I
can't recall the details (it wasn't recent).

Oddly enough, sync does what i expect. It's fsync and fdatasync that I was
surprised by. Guess I'm showing my age ;)




On Sun, Jul 9, 2017 at 5:39 PM, Samuel Holland  wrote:

> On 07/09/17 17:07, Rob Landley wrote:
>
>> Has anybody actually used the conv=sync option in the past 20 years? It
>> doesn't do what you think (that's conv=fsync), instead it pads short reads
>> with zeroes so the input block size is always the same.
>>
>> How is that useful?
>>
>
> It's very useful when trying to image dying hard disks, so bad sectors
> (that cause short reads or read failure) do not affect the alignment of
> the rest of the data in the image file.
>
> Rob
>>
>
> Samuel
>
> ___
> Toybox mailing list
> Toybox@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] I aten't dead.

[Robert Thompson]

Not sure this is relevant, but I just noticed that on my Debian system my
output is a little different from the mentioned outputs. Mainly, it's not
quoting or escaping anything, except for the  tag_ENC values  in -o udev
...

Could be a bug, could be version-skewed behavior, but it's a real world
example.

blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011)


$ blkid -o export /dev/sdb5
LABEL=BiggerStorage
UUID=7af27f9d-3c38-4bff-826f-fb4589608d53
TYPE=ext4

$  blkid -o udev /dev/sdb5
ID_FS_LABEL=BiggerStorage
ID_FS_LABEL_ENC=BiggerStorage
ID_FS_UUID=7af27f9d-3c38-4bff-826f-fb4589608d53
ID_FS_UUID_ENC=7af27f9d-3c38-4bff-826f-fb4589608d53
ID_FS_TYPE=ext4

$  blkid /dev/sdb5
/dev/sdb5: LABEL=BiggerStorage
UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 TYPE=ext4



$  blkid -o udev -t LABEL=BiggerStorage
ID_FS_LABEL=BiggerStorage
ID_FS_LABEL_ENC=BiggerStorage
ID_FS_UUID=7af27f9d-3c38-4bff-826f-fb4589608d53
ID_FS_UUID_ENC=7af27f9d-3c38-4bff-826f-fb4589608d53
ID_FS_TYPE=ext4

(example with escaped characters needed):

$ sudo e2label /dev/sdb5 'Big@$# Storage'
Since I'm not flushing cache, rebooting, or running as root, the change
will only show up on raw access runs. I forgot how to force that, and I
only had a couple of minutes to write this email.

$  sudo blkid -p /dev/sdb5
/dev/sdb5: LABEL=Big@$# Storage
UUID=7af27f9d-3c38-4bff-826f-fb4589608d53 VERSION=1.0 TYPE=ext4
USAGE=filesystem PART_ENTRY_SCHEME=dos PART_ENTRY_TYPE=0x83
PART_ENTRY_NUMBER=5 PART_ENTRY_OFFSET=976562239
PART_ENTRY_SIZE=400387932 PART_ENTRY_DISK=8:16

$ sudo blkid -p -o udev /dev/sdb5
ID_FS_LABEL=Big@$#_Storage
ID_FS_LABEL_ENC=Big@\x24#\x20Storage
ID_FS_UUID=7af27f9d-3c38-4bff-826f-fb4589608d53
ID_FS_UUID_ENC=7af27f9d-3c38-4bff-826f-fb4589608d53
ID_FS_VERSION=1.0
ID_FS_TYPE=ext4
ID_FS_USAGE=filesystem
ID_PART_ENTRY_SCHEME=dos
ID_PART_ENTRY_TYPE=0x83
ID_PART_ENTRY_NUMBER=5
ID_PART_ENTRY_OFFSET=976562239
ID_PART_ENTRY_SIZE=400387932
ID_PART_ENTRY_DISK=8:16

$ sudo blkid -p -o export /dev/sdb5
LABEL=Big@$# Storage
UUID=7af27f9d-3c38-4bff-826f-fb4589608d53
VERSION=1.0
TYPE=ext4
USAGE=filesystem
PART_ENTRY_SCHEME=dos
PART_ENTRY_TYPE=0x83
PART_ENTRY_NUMBER=5
PART_ENTRY_OFFSET=976562239
PART_ENTRY_SIZE=400387932
PART_ENTRY_DISK=8:16


The extra tags are because I read the raw partition to bypass the cache;
the ID_FS_LABEL and ID_FS_LABEL_ENC are the interesting values for this
discussion.

The example label has a space; -o udev substitutes an underscore in the
ID_FS_LABEL tag, but correctly reversibly encodes the full value in the
ID_FS_LABEL_ENC value.
And -o export has the space but fails to quote or escape it (so it's not
actually valid input for eval).

-o export would actually be eval-compatible if the value was unquoted, with
the following characters preceded with backslash: dollarsign, backquote,
doublequote, singlequote, backslash, newline, tab.

Untested, but possibly a good idea would be to substitute the appropriate
backslash-escape characters such as \a, \b, \t, etc wherever possible. A
couple of quick tests show that it's more reliable and simpler to escape
characters in the value than to do quoting correctly. It also seems to work
better between shells (confirmed in mksh and bash 4.2ish, quick-tested in
dash on debian wheezy)

Unfortunately (for a past project), there is no tag containing the device
path (equivalent to the output of -o device), so if you're using any of the
tagged output formats, there's no way to simultaneously get the device and
tags when searching by label or uuid. You'd have to do two calls; one to
get the device, and one to get the tagged output for that device. Just
having a DEVICE=/dev/sdb5 value along with the UUID would have been really
convenient for that project.

At the moment, I don't have any projects that care about any of this, I
just happened to notice it.





On Thu, Feb 26, 2015 at 7:04 PM, Isaac Dunham ibid...@gmail.com wrote:

 On Thu, Feb 26, 2015 at 03:19:28PM -0600, Rob Landley wrote:
 
 
  On 02/26/2015 12:01 PM, Isaac Dunham wrote:
   On Thu, Feb 26, 2015 at 06:26:19AM -0600, Rob Landley wrote:
   On 02/25/2015 10:27 AM, Isaac Dunham wrote:
   On Wed, Feb 25, 2015 at 03:19:23AM -0600, Rob Landley wrote:
   There's a marvelous book called the unix philosophy by mike
 gancarz
   that talks about output intended for humans vs output intended to be
   processed by other tools.
  
   A scriptable tool is one where you can do:
  
 echo $(( $(wc -l  blah) * 3))
  
   If it's scriptable, the output of one tool is naturally the input to
   another. Admittedly this can be annoying to use from the command
 line
   such as the way ls with no arguments will produce no output when
 run
   in an empty directory. But the _reason_ for that is so for i in
 $(ls);
   do blah $i; done doesn't have to filter the ls output to use it in
 a
   script.
  
   Thread hijack/blkid feature I'd like to see (no need to do it now,
 I'm
   willing to try writing it at a later point).
  
   I was just fighting 

Re: [Toybox] Screen vs. tmux (was: optional fatter cat(1))

[Robert Thompson]

Once upon a time, the serial issue would have kept me using screen. But,
these days I use picoterm as the minimal pty--serial connector, and that
works as well with tmux as screen's own serial handling worked with screen.
It also works well without any multiplexer, just letting your (virtual)
terminal handle whatever escape codes are coming, so my smaller utility
images only have to include the tiny picocom binary rather than the much
bigger screen (or tmux+picocom) binary.

Picoterm itself is unfortunately GPL, but it's also pretty simple;
basically just abstracts the serial-pty and the console-pty stuff and plugs
them together with a limited set of command keys for exit, baud-up/down,
etc, and for launching rzsz-style file-transfer programs.

For people who use serial devices on a regular basis, this is very useful.
I am *very* carefully resisting the urge to ask that it be in toybox, at
least until after everything already on the list is done :)

If boxes has a picocom toy, I'll be very happy... if not, I'll eventually
make the time to try to contribute one. Since terminal-side and serial-side
are pretty much a matter of doing the same thing for different reasons, it
might not even significantly change the size of the binary...



On Mon, Dec 29, 2014 at 3:50 AM, David Seikel onef...@gmail.com wrote:

 On Mon, 29 Dec 2014 03:12:03 + (UTC) Jason Spiro
 jasonspi...@gmail.com wrote:

  Rob Landley rob@... wrote:
  
   I plan to implement vi over the next year, but it's one of the four
   realy big commands required by posix (sed, awk, sh, vi) and I've
   been debugging sed against real-world data for _weeks_ now. [...]
  
   There are some others (the kernel build requires bc now, if I'm
   doing less and vi I should be able to do screen, and rsync
   is really useful...) but right now I'm focused on the list for 1.0,
   and there are a lot of smaller commands (and the giant backlog of
   pending cleanups) that could get knocked off the list faster...
 
  In this message, I will tell you why I think toybox should emulate
  tmux instead of GNU Screen.

 Well, if I can go ahead with my plans for boxes for toybox, which will
 eventually include a screen / tmux type system, then no one has to
 convince me to make it more like tmux than screen.  I fully agree with
 you, tmux is much better, it's what I use.  I've configured tmux to be
 friendly to screen users in the past, and convinced one of my clients
 to switch to it.  Actually, he convinced himself with the phrase
 h, you can resize the window panes with your mouse.  Mind you,
 he was resizing MY window panes from another computer at the time,
 which annoyed me watching from the other side of the city.  lol

  Let me begin.
 
  GNU Screen, a terminal multiplexer, is very useful.  Still, I've
  since switched to tmux.  It's a newer terminal multiplexer, and is
  BSD-licensed. It is true that GNU Screen has now started making
  releases again for the first time in half a decade.  Still, I like
  tmux so much that I don't plan to switch back to Screen.

 From my point of view tmux seems to be better designed.

  tmux makes certain operations easier.[1]  For example:  It ships with
  preconfigured keybindings (C-b 0, C-b 1, ..., C-b 9) which let
  you jump to low-numbered windows in just a few keystrokes.  Another
  example:  To renumber a window, you need only hit five keys (C-b .
  9 RET), instead of nine (C-a : n u TAB 9 RET).
 
  tmux is also easier to learn.  For example:  It shows a status line
  (tab bar) by default, instead of forcing users to mess with complex
  configuration options just to get a status line.  See screenshot[2].
 
  tmux is included in the software repositories of Ubuntu, Debian
  stable, and other distros.
 
  tmux's basic keybindings are fairly similar to Screen's.  But,
  instead of Ctrl+A, tmux's default prefix is Ctrl+B.  (This is
  reconfigurable.)

 I do generally configure the hot key and a few others for screen
 compatibility.  So that if I ever have to use screen, then I know what
 to do, and others used to screen can still use my tmux installs.

 Tmux is also built for scripting, which is hard for screen.  I have a
 script that, for instance, connects to a tmux session, switches through
 particular windows in that session, issuing commands to each window, to
 automate some backups, running from a cron job.  The other sysadmin for
 that server had originally used screen, coz she didn't know about tmux,
 and completely failed to get screen to be able to do anything like that.

  You can find a tmux reference card[3] on the Web.
 
  Dear Rob:  I know you mention Screen in your todo.txt file[4].  But
  please consider instead mentioning tmux.  Those who are familiar only
  with good old Screen can either adapt to the nicer user interface
  that tmux provides, or can download and install Screen themselves.


 In the end, I'll likely do what I did for the boxes based editors, make
 it generic, and allow people to build 

Re: [Toybox] [PATCH] fix newline on stdin for

[Robert Thompson]

Yes, I apparently submitted a diff from the tree I used to find the
problem, not the tree I cleanly patched... (Oh well, I'm really stale at C,
so it wasn't *that* clean)

I literally discovered that problem by accident, and submitted a patch
because (bad) code was quicker than a good explanation.
On Dec 24, 2014 9:47 PM, Rob Landley r...@landley.net wrote:

 On 12/12/14 17:19, Robert Thompson wrote:
  I ran across a variance between toybox factor and coreutils factor.
 
  Coreutils factor will accept numbers on stdin separated by any whitespace
  (including newlines and tabs) between integers, but toybox factor was
 only
  accepting one integer per line.

 Really?

   $ factor 
   factor: `' is not a valid positive integer
   $ factor 32 
   factor: `32 ' is not a valid positive integer
   $ factor 32 7
   factor: `32 7' is not a valid positive integer

 Must be newer than Ubuntu 12.04... Ah, on _stdin_. Right. Confirmed.

 Hmmm... might as well make it take both anyway.

  I added a test for this, and hacked factor to give the expected behavior.
  It's not properly indented, and it depends on isspace(), but it seems to
 be
  doing the job.

 I think you left a debug printf in there, it's making all the tests fail,
 including the ones you submitted:

   $ VERBOSE=fail scripts/test.sh factor
   scripts/make.sh
   Generate headers from toys/*/*.c...
   Make generated/config.h from .singleconfig.
   generated/flags.h generated/help.h
   Compile toybox.
   FAIL: factor -32
   echo -ne '' | factor -32
   --- expected  2014-12-23 20:48:38.689595406 -0600
   +++ actual2014-12-23 20:48:38.693595406 -0600
   @@ -1 +1,2 @@
   +-: -32
-32: -1 2 2 2 2 2

 A couple other issues:

   @@ -20,9 +20,11 @@
static void factor(char *s)
{
  long l, ll;
   +  while( *s  s[0]  ! isspace(s[0]) ) {
   +printf(-: %s\n,s);

  l = strtol(s, s, 0);

 *s and s[0] are the same thing.

   @@ -61,6 +63,7 @@
}
  }
  xputc('\n');
   +  }
}

  void factor_main(void)

 As you mentioned, you added a curly bracket level without indenting the
 code.
 I could do a tail call and expect the compiler to turn the recursion into
 iteration, but reindenting the code properly is worth the noise in the
 diff.

 The version I checked in won't error out for 'factor ' or 'factor 36 '
 the way Ubuntu's will, but I think I'm ok with that...?

 Let me know if there are more things to fix.

 Thanks,

 Rob

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] [PATCH] fix newline on stdin for

[Robert Thompson]

I've only seen it used in shell scripts. The most interesting example was
an ancient script I saw a few years ago that used it with seq. It split a
single large directory into a blah/$X/Y/filename nested-cache directory.

Not sure if that is representative, though.
On Dec 25, 2014 1:46 AM, enh e...@google.com wrote:

 On Wed, Dec 24, 2014 at 7:47 PM, Rob Landley r...@landley.net wrote:
  On 12/12/14 17:19, Robert Thompson wrote:
  I ran across a variance between toybox factor and coreutils factor.
 
  Coreutils factor will accept numbers on stdin separated by any
 whitespace
  (including newlines and tabs) between integers, but toybox factor was
 only
  accepting one integer per line.
 
  Really?
 
$ factor 
factor: `' is not a valid positive integer
$ factor 32 
factor: `32 ' is not a valid positive integer
$ factor 32 7
factor: `32 7' is not a valid positive integer
 
  Must be newer than Ubuntu 12.04... Ah, on _stdin_. Right. Confirmed.
 
  Hmmm... might as well make it take both anyway.
 
  I added a test for this, and hacked factor to give the expected
 behavior.
  It's not properly indented, and it depends on isspace(), but it seems
 to be
  doing the job.
 
  I think you left a debug printf in there, it's making all the tests fail,
  including the ones you submitted:
 
$ VERBOSE=fail scripts/test.sh factor
scripts/make.sh
Generate headers from toys/*/*.c...
Make generated/config.h from .singleconfig.
generated/flags.h generated/help.h
Compile toybox.
FAIL: factor -32
echo -ne '' | factor -32
--- expected  2014-12-23 20:48:38.689595406 -0600
+++ actual2014-12-23 20:48:38.693595406 -0600
@@ -1 +1,2 @@
+-: -32
 -32: -1 2 2 2 2 2
 
  A couple other issues:
 
@@ -20,9 +20,11 @@
 static void factor(char *s)
 {
   long l, ll;
+  while( *s  s[0]  ! isspace(s[0]) ) {
+printf(-: %s\n,s);
 
   l = strtol(s, s, 0);
 
  *s and s[0] are the same thing.
 
@@ -61,6 +63,7 @@
 }
   }
   xputc('\n');
+  }
 }
 
   void factor_main(void)
 
  As you mentioned, you added a curly bracket level without indenting the
 code.
  I could do a tail call and expect the compiler to turn the recursion into
  iteration, but reindenting the code properly is worth the noise in the
 diff.
 
  The version I checked in won't error out for 'factor ' or 'factor 36
 '
  the way Ubuntu's will, but I think I'm ok with that...?

 out of curiosity, what practical use is there for factor? even the
 coreutils version gives up around 38 decimal digits, and it's pretty
 slow even with numbers that small.

  Let me know if there are more things to fix.
 
  Thanks,
 
  Rob

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

[Toybox] [PATCH] fix newline on stdin for

[Robert Thompson]

I ran across a variance between toybox factor and coreutils factor.

Coreutils factor will accept numbers on stdin separated by any whitespace
(including newlines and tabs) between integers, but toybox factor was only
accepting one integer per line.

I added a test for this, and hacked factor to give the expected behavior.
It's not properly indented, and it depends on isspace(), but it seems to be
doing the job.



diff -r 51b7d1af353b tests/factor.test
--- a/tests/factor.test Thu Dec 11 20:17:28 2014 -0600
+++ b/tests/factor.test Fri Dec 12 17:10:49 2014 -0600
@@ -16,3 +16,7 @@
 118: 2 131 521 73259\n  
 testing factor 119 factor 119 \
 119: 119\n  
+
+testing factor 3 6 from stdin factor 3: 3\n6: 2 3\n  3 6
+testing factor stdin newline factor 3: 3\n6: 2 3\n  3\n6\n
+
diff -r 51b7d1af353b toys/other/factor.c
--- a/toys/other/factor.c Thu Dec 11 20:17:28 2014 -0600
+++ b/toys/other/factor.c Fri Dec 12 17:10:49 2014 -0600
@@ -20,9 +20,11 @@
 static void factor(char *s)
 {
   long l, ll;
+  while( *s  s[0]  ! isspace(s[0]) ) {
+printf(-: %s\n,s);

   l = strtol(s, s, 0);
-  if (*s) {
+  if (*s  s[0]  32 ) {
 error_msg(%s: not integer);
 return;
   }
@@ -35,10 +37,10 @@
 l *= -1;
   }

-  // Deal with 0 and 1 (and 2 since we're here)
-  if (l  3) {
+  // Deal with 0..3
+  if (l  4) {
 printf( %ld\n, l);
-return;
+continue;
   }

   // Special case factors of 2
@@ -61,6 +63,7 @@
 }
   }
   xputc('\n');
+  }
 }

 void factor_main(void)
___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] lib/passwd.c is_valid_username()

[Robert Thompson]

The most common issue that would impact UTF-8 is programs that use strchr()
and pointer math on strings that originated in the passwd file.

There are also issues about various services that have to implement
different rules than the usual unix world about safe/valid characters. Many
of these tend to assume that usernames would only contain uppercase,
lowercase, underscore, (maybe period), numbers, and weren't coded
defensively. Not long ago, they often still assumed the username was no
more than eight bytes long.

Most of the non-legacy code running on linux  isn't *too* far from being
able to handle UTF-8 usernames. I suspect there would be a surprising
amount of breakage, but with only minor patching needed to resolve most
cases.


On Tue, Sep 16, 2014 at 7:58 AM, Rob Landley r...@landley.net wrote:

 I looked up the actual requirements for posix username sanitizing, and
 it's concerns are _filename_ portability, presumably for the /home/$USER
 directory:


 http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap03.html#tag_03_426


 http://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap03.html#tag_03_276

 (And objecting to - as the first character, presuably so ls $USER
 isn't interpreted as an option. Except you need to be root to create a
 new user, so I'm a bit confused at concerns over attacking the system
 from that direction...? This is also why -- was invented, and scripts
 use printf instead of echo, and so on...)

 These filename issues aren't actually a concern on Linux, which allows
 any character except / and NUL in filenames.

 Note that posix above doesn't allow $ as the last character, which the
 is_valid_username() stuff does, presumably because redhat allows it?

 Is there more information on the use cases here? A username can't have
 : in it because it's a colon delimited field, and it can't have / if
 it's being used as a filename, but other than that why aren't other
 characters allowed? Specifically, why can't we have utf8 usernames?

 Rob
 ___
 Toybox mailing list
 Toybox@lists.landley.net
 http://lists.landley.net/listinfo.cgi/toybox-landley.net

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] Generic editor. Was: fold implementation

[Robert Thompson]

I'm having to fight gmail-web's reformatting more than normal today...


On Sat, Apr 12, 2014 at 9:00 PM, Rob Landley r...@landley.net wrote:

 On 04/08/14 23:46, Robert Thompson wrote:
  In the context of terminal control, 8-bit encoding is a bit
  misleading, especially if you're googling for information. The pre-UCS
  ISO/IEC 2022 character-set extension architecture is actually related,
  but most of the information you find that way will be irrelevant. In the
  context of terminal control, the relevant search term seems to be (8-bit
  terminal control characters) or (8-bit control sequences). The 8-bit
  control sequences are actually related to ISO 2022 (and the term 'C1
  codes' derives from this) ... but the documents talking about
  character-set selection rarely mention anything about terminal control.

 I noticed that.

 I'm strongly tempted to just treat both escape sequences as we saw an
 escape sequence and then the things after that translate the same
 whether they were after the two char or the one char version.

 Except that the 8 bit one doesn't seem compatible with UTF-8, and I want
 the code to deal with UTF-8 properly.


rxvt-unicode and Apple's Terminal.app are both pretty comprehensively UTF-8
compatible. I can't speak to their sanity in any other area, but both of
them handle UTF-8 display strings quite well. They might make good examples
to follow for minimum UTF-8 breakage.

A detail that might save time for anyone looking into Terminal.app... its
emulation model follows dtterm (and thus the ANSI X3.64-1979 and ISO
6429:1992(E) standards) more than it follows xterm or other emulators...
even though its default advertised TERM value is xterm-color.




  Incidentally, the ISO 2022 standard is also how character-set overlaying
  was managed in the VT-series terminals. A good example can be found
  at
 https://en.wikipedia.org/wiki/ISO/IEC_2022#ISO.2FIEC_2022_character_sets
  (the rest of the article is less relevant to terminals). There were
  escape sequences to load one of several alternate C0 sets and escape
  sequences to load one of several alternate C1 sets. These might change
  the byte-to-character interpretation, as well as change the symbols
  displayed for a given codepoint. Hard terminals only usually had a
  couple of these built in as a build-option, and soft-terminals often
  don't bother supporting them at all, especially if they're trying for
  UTF-8 compatibility.

 We're trying for UTF-8 compatibility, and I don't think we'd want the
 complexity of implementing state shifting anyway.


  Certain codes in the C0 range were reserved for control codes (tab,
  backspace, carriage return, newline, etc). With only one or two
  exceptions, the C1 codes were not reserved by standard in the same way.
  However, there were several codes reserved in the C1 range by common
  usage for terminal-control purposes.
 
  The xterm control sequence documentation specifies the 8-bit C1 codes as

 Ooh! xterm control sequence documentation, a google search phrase:

 http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

 (Helps to know what you're looking for...)

 Also turned up:

 http://www.x.org/archive/X11R6.8.1/doc/xterm.1.html

 Which is less useful. (Tekgronix 4014? Double sized characters? Nope.)

  alternate single-byte codes between 0x84 and 0x9f (within the ISO 2022
  C1 control plane)  that are equivalent to certain two-byte codes
  beginning with ESC.

 Once again, how do they interact with unicode? :)

 There are weird unicode keyboard compositing whatsises that say put a
 diacritical mark over that character you just typed or the next
 character will be wearing carmina miranda burana's fruit hat or stuff.
 I have no _clue_ about this, but will probably need to learn it.


Apple apparently spent serious effort getting this to work... If I use the
OSX keyboard composition in a Terminal.app window, I get unicode
characters, and unicode-aware terminal apps receive them undamaged. I have
no clue what they did either, but an example is half the battle ;)

Terminal.app seems to not support meta-keys by default (it suggests in the
help that this is mainly for supporting x11 and some editors, such as
emacs). You can always fake it by hitting escape,f (when your editor or
whatever expects alt-f), but you have to do it quickly, since the escape
sequence timeout is so short in the modern non-low-baud world. I suspect
that any terminal that supports UTF-8 never sends the 8-bit form of meta
keys.

I am unsure how they handle utf-invalid 8-bit values within other escape
codes.  xterm mouse-position  escape codes on terminals with width or
height greater than 95 will contain character values  128, since the
position is encoded as offset+32)
The invisible island xterm control sequence document includes the
mouse-related codes, it turns out.




  Other sources vary slightly, but this source
  (http://rtfm.etla.org/xterm/ctlseq.html) seems to be the closest to a
  common superset

Re: [Toybox] [toybox] fold implementation

[Robert Thompson]

I personally would also find a pure simple single-purpose unfold useful.

If you feel like going just a touch beyond a simple unfold, you might
want to look at the fmt utility. I've seen several scripts in the wild that
used fold and/or fmt. A couple of them used fold to do the folding and fmt
(with really long maximum line specified) to unfold, which I thought was
strange... after all, if you've got fmt, you can use it to do both
folding and unfolding, but whatever.


One thing to be aware of, it seems that there isn't a lot of consensus in
terms of the fmt arguments. If there's a standard, it looks like it's
mostly ignored.

http://en.wikipedia.org/wiki/Fmt

http://www.freebsd.org/cgi/man.cgi?query=fmtsektion=1apropos=0manpath=FreeBSD+6.2-RELEASE

http://www.gnu.org/software/coreutils/manual/html_node/fmt-invocation.html


For what it's worth...


On Wed, Apr 2, 2014 at 8:25 PM, Samuel Holland sam...@sholland.net wrote:

 Hello, everyone.

 Here is a basic implementation of fold[0]. It does not support multibyte
 characters, though that would probably just require more switch cases. This
 is my first contribution, so please comment your thoughts/what I can
 improve.

 I was planning to write an unfold utility that basically did the
 opposite. Although I don't think it's in any standard, would it still be of
 any interest?

 [0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/fold.html





 Regards,
 Samuel Holland sam...@sholland.net
 ___
 Toybox mailing list
 Toybox@lists.landley.net
 http://lists.landley.net/listinfo.cgi/toybox-landley.net


___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net

Re: [Toybox] xargs with blank input

[Robert Thompson]

Not that it's really relevant to most linux environments, but the OSX
version (with a BSD manpage) appears to not execute any commandline that
would have no added arguments. A quick test suggests this is true for both
normal and null-separated modes.

Specifically, echo  | xargs echo foo; echo returned $? will output
exactly one line: returned 0, instead of the two lines seen on my debian
test box. On the other hand, echo bar | xargs echo foo; echo returned
$? behaves identically on both machines.



The manpage mentions that The xargs utility is expected to be IEEE Std
1003.2 (``POSIX.2'') compliant., for what it's worth.

It appears that they are reading the shall construct ... to instruct that
if no arguments are read, there is no complete commandline, thus the xargs
terminates without ever trying to launch a process, but without any error.
My tests on current osx 10.8 indicate that xargs never execs the utility
and returns 0 for success.



On Wed, Oct 16, 2013 at 9:11 PM, ibid...@gmail.com wrote:

 On Wed, Oct 16, 2013 at 03:16:47PM -0400, William Haddon wrote:
  How exactly should this behave? I haven't been able to decipher what
  POSIX has to say about the subject. The GNU version executes the
 POSIX 2008 (I looked at the old tarball of docs...) says:

 shall construct a command line consisting of the utility and argument
 operands specified followed by as many arguments read in sequence from
 standard input as fit in length and number constraints specified by
 the options.
 I read this as Must in all cases construct the command line, since
 there's no note about blank input behaving differently.

  command with no arguments, so that xargs with blank input is
  equivalent to echo and xargs ls with blank input is equivalent
  to ls. Toybox currently appears to do nothing, but actually forks
  a child process which silently seg-faults as a result of calling
  xexec() with argv[0] == NULL. Patching toybox to implement the GNU
  behavior fixes a lot of scripts on my test system that broke when I
  switched the xargs implementation from busybox to toybox, including
  the
  Linux build scripts. I included the patch below, but I haven't
  tested it with all the numerous options that are available to xargs.
  I'm still investigating whether this toybox behavior is the only
  factor contributing to behavior I observed.
 
  William Haddon
 
  diff --git a/toys/posix/xargs.c b/toys/posix/xargs.c
  index e1611ec..6238af8 100644
  --- a/toys/posix/xargs.c
  +++ b/toys/posix/xargs.c
  @@ -160,17 +160,16 @@ void xargs_main(void)
   if (data  !TT.entries) error_exit(argument too long);
   out = xzalloc((entries+TT.entries+1)*sizeof(char *));
 
  -if (dlist) {
  -  struct double_list *dtemp;
  +struct double_list *dtemp;
 
  -  // Fill out command line to exec
  -  memcpy(out, toys.optargs, entries*sizeof(char *));
  -  TT.entries = 0;
  -  TT.bytes = bytes;
  +// Fill out command line to exec
  +memcpy(out, toys.optargs, entries*sizeof(char *));
  +TT.entries = 0;
  +TT.bytes = bytes;
  +if (dlist)
 dlist-prev-next = 0;
  -  for (dtemp = dlist; dtemp; dtemp = dtemp-next)
  -handle_entries(dtemp-data, out+entries);
  -}
  +for (dtemp = dlist; dtemp; dtemp = dtemp-next)
  +  handle_entries(dtemp-data, out+entries);
   pid_t pid=fork();
   if (!pid) {
 xclose(0);
 I thought I saw an issue with brace placement, but I didn't...

 Thanks,
 Isaac Dunham
 ___
 Toybox mailing list
 Toybox@lists.landley.net
 http://lists.landley.net/listinfo.cgi/toybox-landley.net

___
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net