Here's how I ended up handling input arg validation, with meaningful error
messages, as part of a Perl Weekly Challenge a couple years ago. It looks
almost the same as Luca's original, except mine uses "die" instead of
"warn", which means it won't attempt to continue once it encounters a bad
arg.
sub MAIN(Int $line_to_start is copy, #= First line to print
Int $end_line #= Last line to print
where { $_ >= $line_to_start
or die "end_line cannot be less than line_to_start" },
*@input_file #= File(s) to read from. Also reads STDIN.
where { .all.IO.f
or die "Not a file path:\n { .grep({! .IO.f}).join: "\n "
} "}
) {
.say if --$line_to_start < 1
for IO::CatHandle.new(@input_file, $*IN).lines($end_line)
# Alternative would be to use .lines.kv to get line num with line
...
I'm starting to think Luca's found a regression, since using the explicit
variable name instead of the topic fixes the issue. That seems wrong.
-y
On Thu, Apr 14, 2022 at 8:26 PM William Michels via perl6-users <
perl6-us...@perl.org> wrote:
> Works (𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.06):
>
> admin@mbook:~$ raku Luca_Ferrari2.p6
> Usage:
> Luca_Ferrari2.p6 [--dir=<Str where { ... }>]
> admin@mbook:~$ raku Luca_Ferrari2.p6 --dir=foo
> foo
>
> But...warning "Specify the directory [$dir]" isn't printing when
> `--dir=foo` is omitted.
>
> HTH, Bill.
>
> On Tue, Apr 12, 2022 at 1:23 AM Luca Ferrari <fluca1...@gmail.com> wrote:
>
>> On Tue, Apr 12, 2022 at 10:15 AM Luca Ferrari <fluca1...@gmail.com>
>> wrote:
>> >
>> > Hello all,
>> > given this simple program:
>> >
>> > sub MAIN( Str :$dir where { .so && .IO.d // warn "Specify the
>> > directory [$dir]" } ) {
>> > say $dir;
>> > }
>> >
>>
>> Shame on me: it works if I omit the topic and substitute it with the
>> explicit variable, thus:
>>
>> sub MAIN( Str :$dir where { $dir.so && $dir.IO.d // warn "Specify the
>> directory [$dir]" } ) {
>> say $dir;
>> }
>>
>> The only thing that I find in the documentation at
>> <https://docs.raku.org/type/Signature#index-entry-where_clause> is:
>> "The code in where clauses has some limitations: anything that
>> produces side-effects (e.g., printing output, pulling from an
>> iterator, or increasing a state variable) is not supported and may
>> produce surprising results if used. Also, the code of the where clause
>> may run more than once for a single typecheck in some
>> implementations."
>>
>> Is there a better approach to spurting warning messages when a
>> parameter is not correct (without dealing with USAGE() and friends)?
>>
>> Thanks,
>> Luca
>>
>
