develooper Front page | perl.perl5.porters | Postings from December 2018

Re: [perl #133669] Silently ignores commonly-misspelled PERL5OPTSenvironment variable

Thread Previous
From:
Sawyer X
Date:
December 29, 2018 15:04
Subject:
Re: [perl #133669] Silently ignores commonly-misspelled PERL5OPTSenvironment variable
Message ID:
c05ad0cb-756c-fc6e-fd05-f42d549cd0ff@gmail.com
[Top posting]


We can either detect similarity or specific wrongly-spelled. We should
not be doing this for any mismatch, only similar ones.


* If it's fuzzy, we assume the fuzziness does not mean anything.
$ENV{'THING'} is very similar to $ENV{'THINGS'} but for a real reason.
The case that raised this ticket was this exact example in which it
*was* the mistake vs. the right thing, but it could just as easily been
the wrong thing.


* If there was some "ownership" of a list of options, we could maintain
that. For example, /^PERL5/ and then we can maintain they are not
touched if it's not the right one. But then we're getting into
compat-land. We are removing something someone might already be
depending on ($ENV{'PERL5OPT_MINE'}, which might be used).


* We can support specific options (per Paul's patch) but then we're just
arbitrarily picking options. Should we just catch all plurals of our
singular ones (and vice versa)? Should we just add them as we go along?


In the long term, perhaps a Perl5-owned list of environment variables
would serve the user best, but we are both limiting how they use their
own environment variables *and* we are breaking any code that depends on
similar entries.


The last option of specifics is also available, but it requires picking
up a system to decide which are supported and why.


The first option of fuzzy matching is, by far, my least favorite. It's
error-prone, inconsistent, and adds far more costs than exact (or
prefixed) matches.


On 12/9/18 1:03 PM, H.Merijn Brand wrote:
> On Sun, 9 Dec 2018 05:45:01 -0500, David Mertens
> <dcmertens.perl@gmail.com> wrote:
>
>> Merijn,
>>
>> They must be using some kind of fuzzy string matching (
>> https://en.wikipedia.org/wiki/Edit_distance). I think that fuzzy string
>> matching only makes sense for variable and function names, where the
>> language is *given* a string (i.e. variable or function name) and is asked
>> to look it up. Probing the environment is different. For that, the language
>> is giving the string and the environment is asked to look it up.
>>
>> On the one hand, I think this is a bad idea. Compared to a basic
>> environment variable lookup by name, it would be rather costly to get all
>> environment variable names and perform fuzzy matching. On the other hand,
>> if Perl implemented this *in* *general* for environment variable lookups,
>> it could make a whole slew of diagnostics *much* more helpful. For example,
>> if my script asks for $ENV{SOME_THING} but I erroneously set SOMETHING,
>> Perl's fuzzy matching on %ENV misses could warn about which variable was
>> set. Furthermore, given that fuzzy matching would only fire on environment
>> lookup misses, the cost of fuzzy matching would be fairly small in the
>> grand scheme of things.
> IMHO fuzzy lookup should *only* be implemented at compile-time logic,
> otherwise the implication would be a noticeable slowdown. The gain of
> clear and helping error messages on compile-failing scripts would be a
> welcome addition.
>
> Furthermore, %ENV is a tricky one, as you cannot check compile-time
> which variables will be set run-time: $ENV{DBI_DSN} can be set from a
> config file, maybe even in a BEGIN {} block
>
>> The next natural step would be suggesting variable or function names when
>> mis-spellings are found. Another step, suggesting keys when hash
>> mis-spellings are found, seems like it would be too far unless we
>> introduced new syntax for this behavior (i.e. $foo->{{name}} could die with
>> a fuzzy matching suggestion on mis-spellings).
> Again, only for compile-time fails, otherwise all mixin-like modules
> will fail
>
> I for one do *not* like the exception code for one single misspelling
> (like $PERL5OPTS). Either do it for all variables that matter at
> startup ($PERL5LIB, $PERLIO, ...) or not at all
>
>> David
>>
>> On Fri, Dec 7, 2018 at 2:17 AM H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>>
>>> On Thu, 06 Dec 2018 12:28:04 -0800, "James E Keenan via RT" <
>>> perlbug-followup@perl.org> wrote:
>>>  
>>>> On Mon, 19 Nov 2018 17:07:44 GMT, leonerd@leonerd.org.uk wrote:  
>>  [...]  
>>>> If you could propose a patch (including a test), that would probably
>>>> move discussion forward.  
>>> Maybe perl6 people could help/chime in
>>>
>>> $ perl6 -e'my $perl5opt = "monkey"; say $perl5opts'
>>> ===SORRY!=== Error while compiling -e
>>> Variable '$perl5opts' is not declared. Did you mean '$perl5opt'?
>>> at -e:1  
>>> ------> my $perl5opt = "monkey"; say ⏏$perl5opts  
>>>
>>> So they already have the feature to do it for variables, why not
>>> steal/borrow their logic for our environmental variables
>>>
>>> And that could trigger someone else to do it for variables in perl5
>>> too :)

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About