May 23, 2013
On Thu, 23 May 2013 12:29:53 -0400, Kagamin <spam@here.lot> wrote:

> A simple file copy utility.
>
> int main(string[] args)
> {
>    byte[] data = readFile(args[1]);
>    writeFile(args[2],data);
>    return 0;
> }

What is the point of this?

-Steve
May 23, 2013
On Thu, 23 May 2013 12:21:59 -0400, Kagamin <spam@here.lot> wrote:

> On Thursday, 23 May 2013 at 13:56:26 UTC, Steven Schveighoffer wrote:
>> No I mean, I want to pass in all the files in a directory to a windows command line tool.  But the tool has to "opt in" to allow me to use wildcards.
>
> What if the tool handles argv[1] and exits? Or writes to argv[2] if any.

Then you can't pass it more than one parameter?  I don't get the point.

>> No, the shell expands wildcards, not the OS.
>
> It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

Having the expansion of wildcards built into the OS would be bad.  I don't need to get into that.

-Steve
May 23, 2013
On Thursday, May 23, 2013 13:12:53 Steven Schveighoffer wrote:
> >> No, the shell expands wildcards, not the OS.
> > 
> > It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.
> 
> Having the expansion of wildcards built into the OS would be bad. I don't need to get into that.

Agreed. Globbing is a shell thing, so it makes sense that the shell do it. It has nothing to do with the OS. Saying that it had anything to do with OS would be like saying that the fact that you had to escape ( was a feature of the OS. It would make no sense. All of that sort of thing is a feature of the shell. Programs just operate on the arguments that they're given and it just so happens that the shell provides some useful ways for the user to provide larger lists of files without typing them all. The OS has no business being involved in that.

- Jonathan M Davis
May 23, 2013
On Thu, May 23, 2013 at 01:43:52PM -0400, Jonathan M Davis wrote:
> On Thursday, May 23, 2013 13:12:53 Steven Schveighoffer wrote:
> > >> No, the shell expands wildcards, not the OS.
> > > 
> > > It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.
> > 
> > Having the expansion of wildcards built into the OS would be bad. I don't need to get into that.
> 
> Agreed. Globbing is a shell thing, so it makes sense that the shell do it. It has nothing to do with the OS. Saying that it had anything to do with OS would be like saying that the fact that you had to escape ( was a feature of the OS.  It would make no sense. All of that sort of thing is a feature of the shell.  Programs just operate on the arguments that they're given and it just so happens that the shell provides some useful ways for the user to provide larger lists of files without typing them all. The OS has no business being involved in that.
[...]

This reasoning breaks down when the program needs two or more large argument lists. On Windows/MSDOS, you could do things like "rename *.jpeg *.jpg" and it would do the right thing, but this is an utter PITA on Linux: mv doesn't support it, and even a program that *does* support it requires escaping to prevent shell interpolation, thus requiring infelicities like "mv \*.jpeg \*.jpg".

I stand by my statement that wildcards should be handled by the program, not the shell.


T

-- 
A mathematician is a device for turning coffee into theorems. -- P. Erdos
May 23, 2013
On Thu, 23 May 2013 13:47:25 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> This reasoning breaks down when the program needs two or more large
> argument lists. On Windows/MSDOS, you could do things like "rename
> *.jpeg *.jpg" and it would do the right thing, but this is an utter PITA
> on Linux: mv doesn't support it, and even a program that *does* support
> it requires escaping to prevent shell interpolation, thus requiring
> infelicities like "mv \*.jpeg \*.jpg".

This is a HORRIBLE interface.  You are using a wildcard to mean a back reference.  I don't think that's a benefit, and it's actually a good example of why the shell should be your direct interface, not the program itself.

-Steve
1 2 3 4 5
Next ›   Last »