In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>scott@slp53.sl.home (Scott Lurndal) writes:
>[...]
>> Most programs in unix will accept '-?' or '-h' or some other flag
>> to indicate that usage information is to be printed. Many utilities
>> will print usage information if the input arguments are not valid.
>
>Most Unix programs don't use '-?' because '?' is a shell wildcard
>character. If you happen to have files in the current directory named
>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".

Indeed - and this is one of the many reasons why insisting on an option
(any option) to get help is a bad idea. Given that -? is kind of a
standard in the Windows world, many programs that get ported over to
Unix from Windows, will have this misfeature.

--
Modern Conservative: Someone who can take time out from demanding more
flag burning laws, more abortion laws, more drug laws, more obscenity
laws, and more police authority to make warrantless arrests to remind
us that we need to "get the government off our backs".

On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>[...]
>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>> to indicate that usage information is to be printed. Many utilities
>>> will print usage information if the input arguments are not valid.
>>
>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>character. If you happen to have files in the current directory named
>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>
> Indeed - and this is one of the many reasons why insisting on an option
> (any option) to get help is a bad idea. Given that -? is kind of a
> standard in the Windows world, many programs that get ported over to
> Unix from Windows, will have this misfeature.

Many command-line programs get ported to Unix from Windows?

Why don't they adjust their conventions?

/X /Y /Z /? is another convention; that one is smarter.

The system installation can arrange for the first three not
to be paths, and for /? not to match anything due to there
not being a one-character item in the root dir.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>[...]
>>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>>> to indicate that usage information is to be printed. Many utilities
>>>> will print usage information if the input arguments are not valid.
>>>
>>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>>character. If you happen to have files in the current directory named
>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>>
>> Indeed - and this is one of the many reasons why insisting on an option
>> (any option) to get help is a bad idea. Given that -? is kind of a
>> standard in the Windows world, many programs that get ported over to
>> Unix from Windows, will have this misfeature.
>
> Many command-line programs get ported to Unix from Windows?
>
> Why don't they adjust their conventions?
>
> /X /Y /Z /? is another convention; that one is smarter.
>
> The system installation can arrange for the first three not
> to be paths, and for /? not to match anything due to there
> not being a one-character item in the root dir.

So if I want to grep case-insensitively for whole words, and have line
numbers printed with the matched lines - in other words, on the unix
version I'm doing ``grep -win ...'' - should my system installation
arrange for /win to not be a path?

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>[...]
>>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>>> to indicate that usage information is to be printed. Many utilities
>>>> will print usage information if the input arguments are not valid.
>>>
>>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>>character. If you happen to have files in the current directory named
>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>>
>> Indeed - and this is one of the many reasons why insisting on an option
>> (any option) to get help is a bad idea. Given that -? is kind of a
>> standard in the Windows world, many programs that get ported over to
>> Unix from Windows, will have this misfeature.
>
> Many command-line programs get ported to Unix from Windows?
>
> Why don't they adjust their conventions?
>
> /X /Y /Z /? is another convention; that one is smarter.
>
> The system installation can arrange for the first three not
> to be paths, and for /? not to match anything due to there
> not being a one-character item in the root dir.

Having a program misbehave because there happens to be a one-character
item in the root directory is a bad idea. (For example, on Cygwin I
often make /c a symlink to /cygdrive/c for convenience.)

Also, some shells, either by default or depending on options, will print
an error message if a wildcard fails to match.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>[...]
>>>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>>>> to indicate that usage information is to be printed. Many utilities
>>>>> will print usage information if the input arguments are not valid.
>>>>
>>>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>>>character. If you happen to have files in the current directory named
>>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>>>
>>> Indeed - and this is one of the many reasons why insisting on an option
>>> (any option) to get help is a bad idea. Given that -? is kind of a
>>> standard in the Windows world, many programs that get ported over to
>>> Unix from Windows, will have this misfeature.
>>
>> Many command-line programs get ported to Unix from Windows?
>>
>> Why don't they adjust their conventions?
>>
>> /X /Y /Z /? is another convention; that one is smarter.
>>
>> The system installation can arrange for the first three not
>> to be paths, and for /? not to match anything due to there
>> not being a one-character item in the root dir.
>
> Having a program misbehave because there happens to be a one-character
> item in the root directory is a bad idea.

But the problem of wildcard expansion producing that by accident
seems very improbable.

The * pattern won't expand to anything that has a leading slash. You
would have to explicitly do

utility /*

where /* expands to a set of paths the first of which (and possibly
others) look like an option. I don't think that's super common
compared to *.

This seems like less of a threat than

utility *

expanding to arguments that look like - options.

I would also disallow clumping options like /abc instead
of /a /b /c, so the clashing namespace is just one character.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-08-14, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> On 2023-08-14, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>>>> In article <87r0o6mqme.fsf@nosuchdomain.example.com>,
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>[...]
>>>>>> Most programs in unix will accept '-?' or '-h' or some other flag
>>>>>> to indicate that usage information is to be printed. Many utilities
>>>>>> will print usage information if the input arguments are not valid.
>>>>>
>>>>>Most Unix programs don't use '-?' because '?' is a shell wildcard
>>>>>character. If you happen to have files in the current directory named
>>>>>"-x" and "-y", "myprogram -?" expands to "myprogram -x -y".
>>>>
>>>> Indeed - and this is one of the many reasons why insisting on an option
>>>> (any option) to get help is a bad idea. Given that -? is kind of a
>>>> standard in the Windows world, many programs that get ported over to
>>>> Unix from Windows, will have this misfeature.
>>>
>>> Many command-line programs get ported to Unix from Windows?
>>>
>>> Why don't they adjust their conventions?
>>>
>>> /X /Y /Z /? is another convention; that one is smarter.
>>>
>>> The system installation can arrange for the first three not
>>> to be paths, and for /? not to match anything due to there
>>> not being a one-character item in the root dir.
>>
>> Having a program misbehave because there happens to be a one-character
>> item in the root directory is a bad idea.
>
> But the problem of wildcard expansion producing that by accident
> seems very improbable.
>
> The * pattern won't expand to anything that has a leading slash. You
> would have to explicitly do
>
> utility /*
>
> where /* expands to a set of paths the first of which (and possibly
> others) look like an option.

But you are suggesting users type /? for help. That could match a file
and produce almost any other flag as a result. I suspect that was
Keith's main concern.

> I would also disallow clumping options like /abc instead
> of /a /b /c, so the clashing namespace is just one character.

You could (as world king) disallow combining flags with the '-'
convention as well. You /have/ to with the '/' convention which makes
it /less/ smart in my book.

--
Ben.

> .... Given that -? is kind of a
> standard in the Windows world, many programs that get ported over to
> Unix from Windows, will have this misfeature.
>

Command line programs ported from Windows to Unix !!!!! Sounds like an
oxymoron to me :-)

Do you have some in mind?