Re: [Toybox] --help annoyance
On 10/23/2018 02:58 PM, dmccunney wrote: > Their response was to implement provisions of the DKIP specifications. > One requires email to be digitally signed to prove it's from who it > says it's from. Another requires that email not be *changed* en > route. This *breaks* mailing lists, because the list server must > alter the headers as part of what it does. People complained to AOL > and Yahoo, and the response was basically "Don't *use* mailing lists. > Use web forums like we provide!" > > How badly this bites depends on the email server that delivers your > mail. Some will see that the headers on list mail have been altered, > decide it's spam, and discard it undelivered. You'll never know it > was sent. Others (like Gmail) will accept and deliver but label it as > spam. I've had conversations on other lists where I explained the And will then use "this message is like other spam messages" to metastasize through your entire mailbox. Which is a bit hard to undo if any of the messages have expired out of the 30 day window before you can "this is not spam" them. (They're still similar! Now _forever_...) > You can mark an email source as "Never send to Spam", but the last > time I tried it, every message from that source had a banner included > that said it had been passed by a filter I created. This was annoying > enough that I found it simpler to just redirect stuff to the Inbox > that had been flagged as spam. I don't care about the banners, I download all my email via pop3 (because downloading it via imap doesn't work with gmail and thunderbird). Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On Tue, Oct 23, 2018 at 3:26 PM Kevin Spiteri wrote: >> >> > Have you tried the "Never send it to spam" gmail filter action? >> >> I didn't know there was one? Hmmm... didn't find it when I was fishing Nick >> Kralevich's message out of the spam filter. (Somewhere under gear->configure >> account maybe? I've always been reluctant to touch that stuff, _way_ too >> complicated. I just want the spam filtering then pop3 into a local email >> client.) > > You can set the filter through the complicated settings page but there's an > easier path. On the gmail.com front page search box click the arrow, in the > "Has the words" text box type "list:(toybox-landley.net)", click "Create > filter", check "Never send it to Spam", and click "Create filter". I've done it and it works, but it's a PITA. The original problem source was AOL and Yahoo. Both had been thoroughly hacked, and there were oodles of AOL and Yahoo email addresses in the wild. It's trivial to forge a From: address in email, so both became immense sources of spam. Their response was to implement provisions of the DKIP specifications. One requires email to be digitally signed to prove it's from who it says it's from. Another requires that email not be *changed* en route. This *breaks* mailing lists, because the list server must alter the headers as part of what it does. People complained to AOL and Yahoo, and the response was basically "Don't *use* mailing lists. Use web forums like we provide!" How badly this bites depends on the email server that delivers your mail. Some will see that the headers on list mail have been altered, decide it's spam, and discard it undelivered. You'll never know it was sent. Others (like Gmail) will accept and deliver but label it as spam. I've had conversations on other lists where I explained the issue and said "If you use an AOL or Yahoo address to send mail to the list, you have three choices: continue using it but be aware that other list members might not *see* your posts, use another email provider, or drop off the list." You can mark an email source as "Never send to Spam", but the last time I tried it, every message from that source had a banner included that said it had been passed by a filter I created. This was annoying enough that I found it simpler to just redirect stuff to the Inbox that had been flagged as spam. I prefer to read Gmail online in my browser, and don't require a local copy, so I don't download to a local mailstore. Rob does, so his experience may differ if he tries this. __ Dennis ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
> > > Have you tried the "Never send it to spam" gmail filter action? > > I didn't know there was one? Hmmm... didn't find it when I was fishing Nick > Kralevich's message out of the spam filter. (Somewhere under > gear->configure > account maybe? I've always been reluctant to touch that stuff, _way_ too > complicated. I just want the spam filtering then pop3 into a local email > client.) > You can set the filter through the complicated settings page but there's an easier path. On the gmail.com front page search box click the arrow, in the "Has the words" text box type "list:(toybox-landley.net)", click "Create filter", check "Never send it to Spam", and click "Create filter". Do you think I could use it to fix me getting unsubscribed from my own list > daily? (Most recently due to the email I sent an hour ago.) > I don't know about the unsubscribing part. ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On Mon, Oct 22, 2018 at 1:31 PM Rob Landley wrote: > > > > On 10/22/2018 02:04 PM, enh wrote: > > On Thu, Oct 18, 2018 at 11:59 AM Rob Landley wrote: > >> Most commands never _stop_ accepting flags: > >> > >> ls file file file -l > >> rm file file file -i > > > > interesting. in my mental model, i always assume "guideline 9" > > (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html). > > > > (but you're right, coreutils also seems to allow things like `ls / -l`.) > > Yeah, guideline 9 is primarily honored in the breach. (To the point where git > doing it initially confused the heck out of me...) > > Almost always when it does kick in for conventional command line utilities > it's > because the meaning of options changes partway through, such as "xargs -1 ls > -l" > where xargs better not parse that -l because it belongs to ls. > > I implemented "netcat -l" where all the arguments after -l were the command > line > to run and this confused people (commit f492fccc9ceb). > > >> Weren't you the guy who wanted "see --help" instead of dumping help text > >> all the > >> time? :) > > > > was i? i remember being the guy who wanted "(see --help)" rather than > > nothing, because i kept getting bug reports from folks who didn't even > > know there _was_ help. > > Hmmm... Looks like it was more gradual than I remember... 29e75d51d447 then > ab33097058b0 then d3267c60ee48... I'm probably thinking of conversations in > the > wrong context. > > As for accepting --help anywhere... Hmmm. Currently --help and --version are > checked in the first argument before any other argument processing, which > means > they're checked for commands that don't otherwise have a command line (and > there's a flag to suppress it for things like "true" defined to ignore ALL > arguments, so you have to "help true" or "toybox --help true" to get that > one). > > I suppose "touch ./--help ; ls *" is considered pilot error? (One of the > notes-to-self I have about toysh is whether * should expand to -- as its first > argument, which is too simple but how I have the todo item down. Really there > should be some toysh running internal commands context sensitivity, which is > the > same as the "find . | xargs -> find . -print0 | xargs -0" todo item, that > should > probably kick in automatically when you know both ends of the pipeline can > handle it. My version of tab completion being context sensitive. But again, > this > is all way post 1.0 todo items... > > I take it you don't want --version to apply just anywhere? i don't think i've ever used --version other than _after_ getting a weird response and wondering "wait, what am i actually running here?", so, no, i doubt i would ever notice. (my `history` says it's almost always clang, clang-format, gcc, java, ldd, and adb that i'm asking the version of.) if there was something between ^W and ^U that deleted back to the previous command, i'd probably use that for "wait, what's that option called again?". (my `history` says i almost always have `--help` as the only argument anyway.) > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On 10/22/2018 02:04 PM, enh wrote: > On Thu, Oct 18, 2018 at 11:59 AM Rob Landley wrote: >> Most commands never _stop_ accepting flags: >> >> ls file file file -l >> rm file file file -i > > interesting. in my mental model, i always assume "guideline 9" > (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html). > > (but you're right, coreutils also seems to allow things like `ls / -l`.) Yeah, guideline 9 is primarily honored in the breach. (To the point where git doing it initially confused the heck out of me...) Almost always when it does kick in for conventional command line utilities it's because the meaning of options changes partway through, such as "xargs -1 ls -l" where xargs better not parse that -l because it belongs to ls. I implemented "netcat -l" where all the arguments after -l were the command line to run and this confused people (commit f492fccc9ceb). >> Weren't you the guy who wanted "see --help" instead of dumping help text all >> the >> time? :) > > was i? i remember being the guy who wanted "(see --help)" rather than > nothing, because i kept getting bug reports from folks who didn't even > know there _was_ help. Hmmm... Looks like it was more gradual than I remember... 29e75d51d447 then ab33097058b0 then d3267c60ee48... I'm probably thinking of conversations in the wrong context. As for accepting --help anywhere... Hmmm. Currently --help and --version are checked in the first argument before any other argument processing, which means they're checked for commands that don't otherwise have a command line (and there's a flag to suppress it for things like "true" defined to ignore ALL arguments, so you have to "help true" or "toybox --help true" to get that one). I suppose "touch ./--help ; ls *" is considered pilot error? (One of the notes-to-self I have about toysh is whether * should expand to -- as its first argument, which is too simple but how I have the todo item down. Really there should be some toysh running internal commands context sensitivity, which is the same as the "find . | xargs -> find . -print0 | xargs -0" todo item, that should probably kick in automatically when you know both ends of the pipeline can handle it. My version of tab completion being context sensitive. But again, this is all way post 1.0 todo items... I take it you don't want --version to apply just anywhere? Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On 10/18/2018 01:27 PM, Kevin Spiteri wrote: > Sorry for the delay, everything you wrote yesterday wound up in gmail's > spam > filter again. > > Have you tried the "Never send it to spam" gmail filter action? I didn't know there was one? Hmmm... didn't find it when I was fishing Nick Kralevich's message out of the spam filter. (Somewhere under gear->configure account maybe? I've always been reluctant to touch that stuff, _way_ too complicated. I just want the spam filtering then pop3 into a local email client.) Do you think I could use it to fix me getting unsubscribed from my own list daily? (Most recently due to the email I sent an hour ago.) Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On Thu, Oct 18, 2018 at 11:59 AM Rob Landley wrote: > > On 10/18/2018 01:12 PM, enh wrote: > > Yeah, my assumption was that as long as I'm still in the flags, --help > > should > > work. (But not *anywhere*.) > > Most commands never _stop_ accepting flags: > > ls file file file -l > rm file file file -i > > lib/args.c has ^ to stop at the first non-option argument, and > > $ grep 'TOY(.*\^.*)' toys/*/*.c -l | wc -l > 22 > $ grep 'TOY([^^]*)' toys/*/*.c -l | wc -l > 224 > > About 1/10th of the commands use it. (Hence every command accepting -- and the > old argument about whether echo should.) > > > Personally, I often just add --help on the end of what I've already typed > > if I > > get stuck. > > > > For this specific case, I think in my ideal world, a flag that takes > > arguments > > from a list should probably show that list any time it gets something it > > doesn't > > understand? But I don't think this is a regression, so I don't think it > > makes > > sense to try to rush something into this release. > > Weren't you the guy who wanted "see --help" instead of dumping help text all > the > time? :) was i? i remember being the guy who wanted "(see --help)" rather than nothing, because i kept getting bug reports from folks who didn't even know there _was_ help. > So far I think I've only got a list dumper in ps. There's stuff like kill -l > and > getconf -l that does it too, but that's an option to show the list... > > But yeah, accepting --help as well as "help" makes sense... > > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On Thu, Oct 18, 2018 at 11:59 AM Rob Landley wrote: > > On 10/18/2018 01:12 PM, enh wrote: > > Yeah, my assumption was that as long as I'm still in the flags, --help > > should > > work. (But not *anywhere*.) > > Most commands never _stop_ accepting flags: > > ls file file file -l > rm file file file -i interesting. in my mental model, i always assume "guideline 9" (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html). (but you're right, coreutils also seems to allow things like `ls / -l`.) > lib/args.c has ^ to stop at the first non-option argument, and > > $ grep 'TOY(.*\^.*)' toys/*/*.c -l | wc -l > 22 > $ grep 'TOY([^^]*)' toys/*/*.c -l | wc -l > 224 > > About 1/10th of the commands use it. (Hence every command accepting -- and the > old argument about whether echo should.) > > > Personally, I often just add --help on the end of what I've already typed > > if I > > get stuck. > > > > For this specific case, I think in my ideal world, a flag that takes > > arguments > > from a list should probably show that list any time it gets something it > > doesn't > > understand? But I don't think this is a regression, so I don't think it > > makes > > sense to try to rush something into this release. > > Weren't you the guy who wanted "see --help" instead of dumping help text all > the > time? :) > > So far I think I've only got a list dumper in ps. There's stuff like kill -l > and > getconf -l that does it too, but that's an option to show the list... > > But yeah, accepting --help as well as "help" makes sense... > > Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
On 10/18/2018 01:12 PM, enh wrote: > Yeah, my assumption was that as long as I'm still in the flags, --help should > work. (But not *anywhere*.) Most commands never _stop_ accepting flags: ls file file file -l rm file file file -i lib/args.c has ^ to stop at the first non-option argument, and $ grep 'TOY(.*\^.*)' toys/*/*.c -l | wc -l 22 $ grep 'TOY([^^]*)' toys/*/*.c -l | wc -l 224 About 1/10th of the commands use it. (Hence every command accepting -- and the old argument about whether echo should.) > Personally, I often just add --help on the end of what I've already typed if I > get stuck. > > For this specific case, I think in my ideal world, a flag that takes arguments > from a list should probably show that list any time it gets something it > doesn't > understand? But I don't think this is a regression, so I don't think it makes > sense to try to rush something into this release. Weren't you the guy who wanted "see --help" instead of dumping help text all the time? :) So far I think I've only got a list dumper in ps. There's stuff like kill -l and getconf -l that does it too, but that's an option to show the list... But yeah, accepting --help as well as "help" makes sense... Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
> > Sorry for the delay, everything you wrote yesterday wound up in gmail's > spam > filter again. > Have you tried the "Never send it to spam" gmail filter action? ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
Yeah, my assumption was that as long as I'm still in the flags, --help should work. (But not *anywhere*.) Personally, I often just add --help on the end of what I've already typed if I get stuck. For this specific case, I think in my ideal world, a flag that takes arguments from a list should probably show that list any time it gets something it doesn't understand? But I don't think this is a regression, so I don't think it makes sense to try to rush something into this release. On Thu, Oct 18, 2018, 10:39 Rob Landley wrote: > Sorry for the delay, everything you wrote yesterday wound up in gmail's > spam > filter again. > > On 10/17/2018 04:51 PM, enh wrote: > > i wanted to check that the Android scheduler policy output wasn't > > broken by recent changes, but i can't remember what the -O option is > > called... > > > > # ps -A -O > > ps: Missing argument to -O (see "ps --help") > > And "ps --help" says: > > Which FIELDs to show. (-o HELP for list, default = -o PID,TTY,TIME,CMD) > > I.E. "ps -O help". (All the fields are case insensitive, "help" is just a > special field.) > > The global "--help" has only ever been recognized as the first option. > Should I > change that? > > The problem is it would ignore all other options, meaning "rm -rf file > file file > file file --help file file" would prevent those files from getting deleted, > which seems like a security issue waiting to happen. > > > fair enough. (though maybe we should have a special case for things > > that take an option and just assume that you need to know what the > > options are?) > > > > # ps -A -O --help > > ps: bad -O '--help' > > ^ > > I take it you'd like -O to also accept "ps -O --help" as the field name? > > > okay, fair enough. that one seems unavoidable. > > > > # ps -A --help > > ps: Unknown option help (see "ps --help") > > > > that's pretty annoying though... > > That's "--help only works as the first argument" again. > > If you're ok with the security hole I could make it check all the > arguments. I'd > have to duplicate to -- check to stop early, it's not lib/args doing this > because lots of standalone commands build without lib/args and it saves > several > kilobytes in each of those. That's this blob in main.c dropping it out: > > https://github.com/landley/toybox/blob/master/main.c#L60 > > Rob > ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
Re: [Toybox] --help annoyance
Sorry for the delay, everything you wrote yesterday wound up in gmail's spam filter again. On 10/17/2018 04:51 PM, enh wrote: > i wanted to check that the Android scheduler policy output wasn't > broken by recent changes, but i can't remember what the -O option is > called... > > # ps -A -O > ps: Missing argument to -O (see "ps --help") And "ps --help" says: Which FIELDs to show. (-o HELP for list, default = -o PID,TTY,TIME,CMD) I.E. "ps -O help". (All the fields are case insensitive, "help" is just a special field.) The global "--help" has only ever been recognized as the first option. Should I change that? The problem is it would ignore all other options, meaning "rm -rf file file file file file --help file file" would prevent those files from getting deleted, which seems like a security issue waiting to happen. > fair enough. (though maybe we should have a special case for things > that take an option and just assume that you need to know what the > options are?) > > # ps -A -O --help > ps: bad -O '--help' > ^ I take it you'd like -O to also accept "ps -O --help" as the field name? > okay, fair enough. that one seems unavoidable. > > # ps -A --help > ps: Unknown option help (see "ps --help") > > that's pretty annoying though... That's "--help only works as the first argument" again. If you're ok with the security hole I could make it check all the arguments. I'd have to duplicate to -- check to stop early, it's not lib/args doing this because lots of standalone commands build without lib/args and it saves several kilobytes in each of those. That's this blob in main.c dropping it out: https://github.com/landley/toybox/blob/master/main.c#L60 Rob ___ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
