Issue multiple commands in one call

[oniony]

Daan Bakker said:

I'm working on a script to automatically tag all my files, but I noticed it is very slow and requires a ton of IO (to save the db) to call "tmsu (un)tag [file] [tags]" for every file. (In my situation I do need to give every file different tags, so I cannot simply use the -r flag on the directory)
The solution I propose is to add an option that makes tmsu read commands from STDIN (instead of using parameters). Tmsu could then commit only after the last command was received.

[oniony]

Sounds reasonable, I'll have a think about how it can work.

FYI, I have made some changes in revisions be219acd and 0d4c6abd to improve untagging performance. (I will still look at your suggestion of reading actions from standard input.)

[oniony]

This is now implemented. Pass - as the sole argument in order to read from standard input. Let me know of any issues.

df2c065

[0ion9]

Good to see this progressing.

I have a bug report:
The parser breaks on arguments containing spaces.

for example the pretty conventional usage tag --tags="foo bar":

• echo foo > /tmp/foo
• create this input file, testcase1.txt:

-D /tmp/foo-bar.db tag --tags="foo bar" /tmp/foo
-D /tmp/foo-bar.db tags /tmp/foo

• tmsu - < testcase1.txt

Result:
tmsu: New tag '"foo'.
tmsu: bar": no such file

If you make the obvious modification, removing the quotes, that is broken in a slightly different way:

tmsu: New tag 'foo'.
tmsu: bar: no such file
"foo

• This problem also comes up with any filename that has a space in it. You can observe this by changing the database name to /tmp/foo bar.db in the above test-case.
• I suggest that you either need a different convention (for example, one argument per line, with the end of a command being blank line or EOF), or need to allow spaces to be escaped. I'm personally in favor of the former, since it makes script generation very simple.

To rewrite the above test-script in the format I suggested, looks like this:

-D=/tmp/foo-bar.db
tag
--tags=foo bar
/tmp/foo

-D=/tmp/foo-bar.db
tags
/tmp/foo

A bit more stretched out, but pretty clear imo

I made a working prototype of this idea -- see read_args(), parse_file() , and I realized that a 'prelude' is also a good option. That's a section that comes before actual commands, specifying options to share between every executed command. To illustrate, that would look like

-D=/tmp/foo-bar.db

tag
--tags=foo bar
/tmp/foo

tags
/tmp/foo

for the same test-script, removing the need to repeat global options like -D or -v in each individual commandline.

[oniony]

Thanks, I'll take a look. Not sure about the argument per line idea as I'd
rather keep a single syntax, plus you'd have to have an unintuitive blank
line between each subcommand.

I think the better solution is if I build a line parser that's aware of
quotation marks.

Sorry to get your hopes up when it so blatantly doesn't work.
On 18 Dec 2014 02:23, "0ion9" notifications@github.com wrote:

The parser breaks on spaces.
for example the pretty conventional usage tag --tags="foo bar":

• echo foo > /tmp/foo
• create this input file, testcase1.txt:

-D /tmp/foo-bar.db tag --tags="foo bar" /tmp/foo
-D /tmp/foo-bar.db tags /tmp/foo

• tmsu - < testcase1.txt

Result:
tmsu: New tag '"foo'.
tmsu: bar": no such file

If you make the obvious modification, removing the quotes, that is broken
in a slightly different way:

tmsu: New tag 'foo'.
tmsu: bar: no such file
"foo

This problem also comes up with any filename that has a space in it.
You can observe this by changing the database name to /tmp/foo bar.db in
the above test-case.

I suggest that you either need a different convention (for example,
one argument per line, with the end of a command being blank line or EOF),
or need to allow spaces to be escaped. I'm personally in favor of the
former, since it makes script generation very simple.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[oniony]

Also, you can specify the database before the instruction to read from
standard input. In fact I believe you have to otherwise it will have
already opened the database by that point.
On 18 Dec 2014 02:30, "Paul Ruane" paul.ruane@oniony.com wrote:

Thanks, I'll take a look. Not sure about the argument per line idea as I'd
rather keep a single syntax, plus you'd have to have an unintuitive blank
line between each subcommand.

I think the better solution is if I build a line parser that's aware of
quotation marks.

Sorry to get your hopes up when it so blatantly doesn't work.
On 18 Dec 2014 02:23, "0ion9" notifications@github.com wrote:

The parser breaks on spaces.
for example the pretty conventional usage tag --tags="foo bar":

• echo foo > /tmp/foo
• create this input file, testcase1.txt:

-D /tmp/foo-bar.db tag --tags="foo bar" /tmp/foo
-D /tmp/foo-bar.db tags /tmp/foo

• tmsu - < testcase1.txt

Result:
tmsu: New tag '"foo'.
tmsu: bar": no such file

If you make the obvious modification, removing the quotes, that is broken
in a slightly different way:

tmsu: New tag 'foo'.
tmsu: bar: no such file
"foo

This problem also comes up with any filename that has a space in it.
You can observe this by changing the database name to /tmp/foo bar.db in
the above test-case.

I suggest that you either need a different convention (for example,
one argument per line, with the end of a command being blank line or EOF),
or need to allow spaces to be escaped. I'm personally in favor of the
former, since it makes script generation very simple.

—
Reply to this email directly or view it on GitHub
#6 (comment).

[oniony]

Parsing now handles quoted text correctly.

763ed92

[BourgeoisBear]

Was this feature removed?

Building from latest, I get:

$ tmsu -
tmsu: invalid subcommand '-'