On Wed, 22 May 2013 21:58:38 -0400, 1100110 <0b1100110@gmail.com> wrote:

> Just get zsh, apparently it doesn't glob unless it actually matches
> something.
>
> So unless there's a file named -unittest="package.name.version" it's all
> good.

All shells do this.  I don't know what the behavior would be otherwise.

-Steve

23-May-2013 01:51, H. S. Teoh пишет:
> On Tue, May 21, 2013 at 08:56:13PM +0200, Jacob Carlborg wrote:
>> On 2013-05-21 20:34, Nick Sabalausky wrote:
>>
>>> Ugh, yea, that's right. I love the unix shell, but I'm convinced that
>>> having the shell expand globs was a colossal mistake.
>>
>> I think it's mostly very handy.
> [...]
>
> I'm a total unix shell geek (my X11 environment is basically a glorified
> terminal, no window decorations, everything is maximized, no mouse
> dependence, etc.), but I have to agree that having the shell expand
> globs was a mistake.
>
> The *reasoning* behind it was NOT a mistake: you want a standard syntax
> for wildcards across the board, that users can rely on, instead of cp
> taking one syntax, mv another syntax, and ls yet another syntax. (One
> example of this latter is the sheer number of regex variations on a
> typical unix installation, many of which are mutually incompatible, or
> compatible but with subtle variations that nobody can remember.  It's an
> embarrassment!)
>
> The *chosen solution*, though, was mistake. The correct solution was to
> have a globbing function in a standard library that programs would use
> to expand wildcards.

Windows had it in WinAPI - FindFirst/FindNext. Programmers basically had it yet it didn't mean they used it even half-consistently (nor it was complete glob pattern).


-- 
Dmitry Olshansky

On Wednesday, 22 May 2013 at 18:27:07 UTC, Jonathan M Davis wrote:
> Problem solved. _Not_ having the shell expand globs would be horrific. Every
> program would then have to handle that internally, and the results would be
> incredibly inconsistent.

Interesting... Does it expand wildcards when you execute the program with a syscall like evecve(2)?

On Wednesday, 22 May 2013 at 17:06:59 UTC, Timothee Cour wrote:
> it's only module level granularity.
>
> I agree that a library solution is the way to go, however there needs to be
> a way to have finer granularity, ie being able to call individual unittests.
> I gave the reasons in the 2nd post in this thread. Syntax would be:
> unittest(test_fun){...}
> having a short syntax such as this will make people use it.
>
> digressing, I wish there would be a simple non-anonymous way to vote for
> such features, to see whether most people agree/disagree. It's easier than
> voting by email, which invariably gets lost in digressions (as I'm doing
> here).

For a real life project you probably need a unittest framework. Current approach is for an optimistic case when you mostly have green test runs and just unittests are enough to test the whole system.

On Tuesday, 21 May 2013 at 18:58:33 UTC, Steven Schveighoffer wrote:
> Fully disagree!  For free, every single command line application, including custom ones, handles expansion in exactly the same way.  Compare to windows command line...

Something wrong with FindFirstFile and FindNextFile functions?

On Thu, 23 May 2013 09:49:59 -0400, Kagamin <spam@here.lot> wrote:

> On Tuesday, 21 May 2013 at 18:58:33 UTC, Steven Schveighoffer wrote:
>> Fully disagree!  For free, every single command line application, including custom ones, handles expansion in exactly the same way.  Compare to windows command line...
>
> Something wrong with FindFirstFile and FindNextFile functions?

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.

In other words, the tool receives "*.*" as a parameter, and it is responsible for expanding.  If it doesn't, I'm SOL.

Compare to Unix, I don't care what the tool supports, I am in control of the expressiveness of what I want to say.

-Steve

On Thu, 23 May 2013 09:38:05 -0400, Kagamin <spam@here.lot> wrote:

> On Wednesday, 22 May 2013 at 18:27:07 UTC, Jonathan M Davis wrote:
>> Problem solved. _Not_ having the shell expand globs would be horrific. Every
>> program would then have to handle that internally, and the results would be
>> incredibly inconsistent.
>
> Interesting... Does it expand wildcards when you execute the program with a syscall like evecve(2)?

No, the shell expands wildcards, not the OS.

-Steve

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.

> No, the shell expands wildcards, not the OS.

It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

A simple file copy utility.

int main(string[] args)
{
  byte[] data = readFile(args[1]);
  writeFile(args[2],data);
  return 0;
}

On Thu, May 23, 2013 at 06:21:59PM +0200, Kagamin 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.
> 
> >No, the shell expands wildcards, not the OS.
> 
> It was just a sarcastic comment about incredible consistency of wildcard expansion in linux.

Exactly!!

That's why I said that the chosen solution was wrong, even though the idea behind it (consistent wildcards across the board) was sound. Putting this expansion in the shell was just a poor choice. It should either be done by the program itself (via a common library routine to ensure consistency) or by the kernel (so exec*() will automatically inherit it). Putting it in the shell led to a series of consequences that eventually produced the stupid inconsistencies we have to deal with today.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.