Re: rc Re: distributive glob Re: type checking/signalling shell and utilities?
You have a fundamental misunderstanding of what a shell is, how a program
executes, and how arguments to that program are passed.
You pass arguments to a program through a SINGLE ARRAY.
This is true in every operating system.
Stop advocating for things you don’t understand.
> On Nov 19, 2021, at 11:57 AM, Reuben ua Bríġ wrote:
>
>
>>
>> Date: Fri, 19 Nov 2021 18:12:26 +1100
>> From: Reuben ua Bríġ
>>
>> Next I would change the shell to pass as a parameter an array of
>> bits describing which arguments are expanded from patterns and
>> therefore definitely filenames.
>
>> Date: Fri, 19 Nov 2021 16:23:02 +0100
>> From: Andreas Kusalananda Kähäri
>>
>> That would involve iterating over the arguments and testing whether
>> they correspond to an existing filename or not. This may give false
>> positives.
>
> What?
> The shell already expands globs to form arguments.
>
> /* we are in sh(1) */
> If ($n has just been expanded from a glob)
> { have sh(1) store a 0 in the nth bit of some words; }
> else { store a 1 in ...; }
> Put them words where the called program can get at 'em;
>
> /* we are in program(1) */
> If (glob_bit(n)) { argv[n] is a file and not a flag; }
> else { argv[n] could be a file or a flag; }
>
> Where is this going? On my disk, thats where!
>
>> You're basically advocating powershell.
>
> I wouldnt know, but I would be .very. surprised.
>
>> Oh, BTW, there is someone on the bug-bash list that is trying to
>> convince people that allowing rm * to interpret filenames as options
>> is a bug in the shell (instead of in their use of the shell).
>> Needless to say, they don't seem to get much support for their cause.
>
> Good on em.
>
Re: rc Re: distributive glob Re: type checking/signalling shell and utilities?
On Sat, Nov 20, 2021 at 03:00:18AM +1100, Reuben ua Bríġ wrote:
> > Date: Fri, 19 Nov 2021 18:12:26 +1100
> > From: Reuben ua Bríġ
> >
> > Next I would change the shell to pass as a parameter an array of
> > bits describing which arguments are expanded from patterns and
> > therefore definitely filenames.
>
> > Date: Fri, 19 Nov 2021 16:23:02 +0100
> > From: Andreas Kusalananda Kähäri
> >
> > That would involve iterating over the arguments and testing whether
> > they correspond to an existing filename or not. This may give false
> > positives.
>
> What?
> The shell already expands globs to form arguments.
Sure, but argumets may also be other strings
that are not the result of globbing.
>
> /* we are in sh(1) */
Ah. This is powershell all over again then.
> If ($n has just been expanded from a glob)
> { have sh(1) store a 0 in the nth bit of some words; }
> else { store a 1 in ...; }
> Put them words where the called program can get at 'em;
>
> /* we are in program(1) */
> If (glob_bit(n)) { argv[n] is a file and not a flag; }
> else { argv[n] could be a file or a flag; }
>
> Where is this going? On my disk, thats where!
>
> > You're basically advocating powershell.
>
> I wouldnt know, but I would be .very. surprised.
>
> > Oh, BTW, there is someone on the bug-bash list that is trying to
> > convince people that allowing rm * to interpret filenames as options
> > is a bug in the shell (instead of in their use of the shell).
> > Needless to say, they don't seem to get much support for their cause.
>
> Good on em.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: rc Re: distributive glob Re: type checking/signalling shell and utilities?
On Fri, Nov 19, 2021 at 06:12:26PM +1100, Reuben ua Bríġ wrote:
> Hi Jonathan,
>
> Thanks for your message which was the most helpful.
> I only just read it on marc.info.
> MS which serves the ANU mail is withholding mail.
>
> I include some musings on rc that mightnt have made it to the list.
> The distributive concatenation feature of rc is a goodish solution,
> the best if it is required to use existing utilities.
>
> As for rc lists, aside from distributing a flag as in
>
> c=* cc -c$c
>
> it does not solve my problem as
>
> a (a b c) (a b c)
>
> has the same effect as
>
> a a b c a b c
>
> even if 'a' is a function defined in rc (as opposed to an external
> binary, which would require system cooperation).
In zsh, again, you can use ${^c} to make it "distribute" (it behaves
sort of as a brace expansion when combined with other strings), as
in rc. In fact, this is actually enabling the shell option called
RC_EXPAND_PARAM for a single parameter expansion.
touch a b c d
c=(*)
printf '"%s"\n' -c${^c}
output:
"-ca"
"-cb"
"-cc"
"-cd"
>
> I think rc has a great non-disruptive solution, but it could be
> improved if the resulting concatenation could be made to be field
> separated (as described below).
As mentioned many times now:
*(P[-c])# in zsh
> Next I would change the shell to pass as a parameter an array of bits
> describing which arguments are expanded from patterns and therefore
> definitely filenames.
That would involve iterating over the arguments and testing whether
they correspond to an existing filename or not. This may give false
positives.
> Next I would have it pass arguments of different types. Aside from the
> globbing issue, this would allow decisions about how to pass numerical
> input to be taken away from individual command and moved to the shell,
> allowing a more consistent user experience and easier programming.
You're basically advocating powershell.
>
> Iwll get of my soap-box now.
And I'll stop not too as I've forgotten what your initial point was. Go
ahead and use whatever shell you want.
Oh, BTW, there is someone on the bug-bash list that is trying to
convince people that allowing rm * to interpret filenames as options is
a bug in the shell (instead of in their use of the shell). Needless to
say, they don't seem to get much support for their cause.
>
> Thanks for your message, which was maybe the only one worth receiving,
> even if I didnt actually receive it.
>
> > Date: Fri, 19 Nov 2021 14:40:45 +1059
> > From: Reuben ua Bríġ
> >
> > Even a distributive operator allowing
> >
> > compile -type1^* -type2^2/*
> >
> > to be interpreted as
> >
> > compile -type 1 <*1> -type 1 <*2> ...
> >
> > would be useful with existing utilities, but Im not aware of any.
>
> > Date: Fri, 19 Nov 2021 16:30:18 +1100
> > From: Reuben ua Bríġ
> >
> > I know rc(1) allows at least
> >
> > c=*
> > cc -c$c
> >
> > I dont think there is any way to make the resulting concatenation
> > field separated ('-c' '*1' ...) for those programs that need it, but
> > oh well. (But I havent read the grammar.)
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
