On Fri Mar 09 15:41:38 2018, DJERIUS wrote:
Show quoted text> On Fri Mar 09 15:02:35 2018, REHSACK wrote:
> > On Fri Mar 09 14:54:14 2018, DJERIUS wrote:
> > > On Fri Mar 09 12:42:28 2018, REHSACK wrote:
> > > > I do not understand what your request is.
> > > >
> > > > I tried:
> > > >
> > > > sudo -u _calendar perl -Mblib -MData::Dumper -MFile::HomeDir -le
> > > > 'delete $ENV{HOME}; my $dd = File::HomeDir->my_dist_data( "File-
> > > > HomeDir" ); print Dumper {dist_data => $dd}'
> > > >
> > > > an receive as expected and documented etc.:
> > > >
> > > > $VAR1 = {
> > > > 'dist_data' => undef
> > > > };
> > > >
> > > > What do you expect File::HomeDir shall do or try? Fetch current
> > > > privilege escalation code, run it and create some directories
> > > > with
> > > > super-power? Or throw an exception instead of returning undef?
> > >
> > >
> > > Why in the world are you deleting $ENV{HOME}? What does that have
> > > to
> > > do with my report?
> >
> > I strongly suggest 'man sudo' and keep calm.
> >
> > > Why are you replying with sarcasm? I sent you a polite message and
> > > I
> > > expect to be treated politely, not with sarcasm.
> >
> > I don't know how polite a message is "Your code does XY since ages. I
> > know that is something failing. Please do."
>
> I did not attack you, I did not attack your code, I did not impune
> your intelligence. I did nothing but point out a discrepancy in the
> documented behavior. I looked at the code to try and understand what
> was happening in the hopes that it would improve the quality of my
> report. I made no suggestion as to which was correct, the
> documentation or the behavior. That would be presumptuous. It's your
> code, your documentation. I cannot determine which is correct.
You didn't ask for clarification. You asked for fixing the assumption
of
Show quoted text> I know of at least one package (PAUSE::Packages) which depends upon
>
> File::HomeDir->my_dist_data(..., { create => 1 } )
>
> always returning a valid directory name, which is what the
> documentation indicates.
And I told you, that the documentation doesn't promise that under
any circumstance the complete path is created.
Show quoted text> > > My report clearly states that the documentation is incorrect if
> > > if File::HomeDir->my_data returns undef, that on OS X, my_data
> > > refers
> > > to
> > > "$USER/Library/Application Support", and if that directory does not
> > > exist the create flag
> > > is ignored.
> >
> > $a and $b and $c;
> > if $a is false, $b and $c are not evaluated. This is called short
> > circuit.
>
>
> > This is the expected behavior. There is no statement, that my_data()
> > is created unless exists - this would be weird anyway. In opposite,
> > it
> > is documented that my_data() will return undef unless the expected
> > directory is existing. Mind the short circuit?
>
> Please note that the call is to my_dist_data(), not my_data().
Your initial post clearly states that you know that the behavior is
caused by
Show quoted text> There
> is no documentation indicating that my_dist_data and my_data are
> related in any way.
That is in best case ignorance. Please re-read the documentation
of both methods again.
Show quoted text> They are system dependent, so the user *cannot*
> make an assumption about their relationship. The user must depend upon
> the documentation.
>
> If my_dist_data( create => 1 ) will fail if my_data does not exist,
> then please document it.
The documentation for my_dist_data says:
Show quoted text> ... This directory will be of course a subdirectory of C<my_data> ...
And further:
Show quoted text> ... remember that C<File::HomeDir>'s policy
> is to return C<undef> if the directory doesn't exist ...
So please don't tell that it is not documented. You referred
to that behavior in your initial post.
