spaces in target names about stu HOT 10 CLOSED

Hi Aaron

There are three ways to specify targets in Stu:

(1) stu -c FILENAME
(2) stu -C EXPRESSION
(3) stu EXPRESSION...

(1) The -c option allows passing exactly one filename
(2) The -C option allows to pass any targets in stu dependency syntax
(3) EXPRESSIONs given on the command line without an option character are interpreted in the same way as arguments to the -C option.

This means that stu "a b" will work as if you had a top-level target at the beginning of the input file like this:

@ALL: a b ;

This explains the need to use «stu "'a b'" or similar. The question now is: Does it make more sense for optionless arguments to be interpreted like in the -c option, or like in the -C option? The current solution allows these invocations:

stu '?A' # Re-build the file 'A' only if it already exists
stu @test # Build phony target @test

These would not be possible with optionless arguments working like the -c option.

A third way to do would be to have an extra syntax for optionless arguments that allows any of these.

I'm torn on which approach is the best.

from stu.

I see now, thanks. Being able to use [ ] dependencies could be useful.

I should have carefully read the output of stu -h before posting!

An alternative might be to say that -c and -C are argument-less options which control how all following non-option arguments (up to the next -c or -C) are treated.

So, stu -c x y z -C P Q R would treat x y and z as raw filenames, and P Q R would be have Stu syntax applied to them.

Then, a user could define a bash alias stuc=stu -c which would effectively means that -c is the default treatment when they use stuc.

from stu.

(closing. -c is the way to request 'raw' filenames)

from stu.

On second thoughts, my last suggestion would have problems also. If stu -c x y -C P Q would treat both x and y as raw filename targets, then what about:

stu -c -K x y

Would -K be a filename, or the option?

So perhaps -c and -C should continue being options-with-arguments, as currently, but should also have the effect of changing how following non-options arguments are treated. Although this is getting a bit too complex to describe clearly in a simple -h help page!

from stu.

Having options like -c and -C change the meaning of subsequent non-option arguments could only be implemented by not using getopt() and parsing the command line by hand, and I don't think that's a good idea.

Rather, a new syntax could be defined for optionless arguments, which allows characters such as []@?!& and maybe also () to have their Stu meaning, but whitespace to be allowed as part of filenames. Other characters would all be allowed as part of filenames. Parsing would be simple because each argument would be exactly one dependency. This will reduce confusion for users and the -c and -C option will retain their meanings.

I'm adding this to the todo list for later.

from stu.

I've already got an implementation, based on getopt and a small change to your code :-)

If the first letter to the getopt optstring is '-', then it is possible to easily process arguments in a slightly different way that is sensitive to the order.

From the manpage: If the first character of optstring is '-', then each nonoption argv-element is handled as if it were the argument of an option with character code 1. (This is used by programs that were written to expect options and other argv-elements in any order and that care about the ordering of the two.) The special argument "--" forces an end of option-scanning regardless of the scanning mode.

That's from the man page for getopt(3). However, The use of '+' and '-' in optstring is a GNU extension. I guess this would be a problem on non-GNU machines.

(Actually, I think a fully-portable implementation of my idea, based on "POSIX" getopt, is possible easily also.)

from stu.

Hi

I would not use the GNU extensions. I see now how it could be implemented using only POSIX getopt(). However: do you have a use-case where a 'switching' -c and -C would be useful, which would not be covered by the new syntax I described above? Are you calling Stu using glob expansion on the arguments?

from stu.

Are you calling Stu using glob expansion on the arguments?

I often have spaces in filenames, and sometimes I have other unconventional characters. It's possible that sometime I will have @ at the start of a filename. Therefore, I would like to know that I can call stu in such a way that filenames are respected as is, without any exceptions. If I have a complex chain of commands (find -print 0 | xargs -0 stu -c), then I want to be confident each step is robust. At the moment, I would need to pass -L 1 to xargs to ensure that each invocation stu receives just one argument and therefore gets assigned to -c.

I think I'll write a little program, stuc, that places -c before every non-option argument. That could then be safely used with xargs (without the need for -L 1). I often have my own custom wrappers around commands, so I don't mind doing this.

from stu.

Hi Aaron, there is now a -J option in master which does exactly that: make all non-option arguments be interpreted as straight filenames.
Cheers
Jérôme

from stu.

Thanks!
I had compiled my own hacky version of the code that implemented something
similar - it's good to be back on the main branch so I can keep up to date.

Aaron

On 20 May 2016 at 14:24, Jérôme Kunegis [email protected] wrote:

Hi Aaron, there is now a -J option in master which does exactly that: make
all non-option arguments be interpreted as straight filenames.
Cheers
Jérôme

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
#4 (comment)

from stu.