experchange > perl

Rainer Weikusat (11-18-19, 11:28 PM)
Eli the Bearded <*> writes:
> In comp.lang.perl.misc, Rainer Weikusat <rweikusat> wrote:
> If a path has a bunch of forward and backward elements in it, it's the
> sysadmin who created something fucked up? No, the source of the path was
> fucked up.


See other posting about "pathname syntax" vs "problems which can't be
solved".

>> Apart from that, you aren't replying to my text at all. So, why not post your
>> > Use one of the modules suggested else-thread.

>> "Grossly free downloads on the internet !!1" recommendation on its own?

> CPAN code mentioned by others (Path::Tiny) or shipped with Perl (Cwd's
> abs_path) is "Grossly free downloads on the internet !!1" now?


Yes. Whenever (or "often wheb") some kind of algorithm for solving a
particular problem could be discussed, someone jumps in from the
sidelines and points out that "loads of stuff can be downloaded for free
from the net !!25". Or rather "Download This Code Now Lest Terrible Harm
Will Befall You !!33.7". Or something like this. But algorithms
implemented in $language are interesting in their own right and that
some people apparently really cannot stand that ought to be their
problem.
Keith Thompson (11-19-19, 08:55 PM)
Rainer Weikusat <rweikusat> writes:
> Keith Thompson <kst-u> writes: [...]
> You're conflating to unrelated issue here:
> - remove syntactically redundant parts from a path name
> - determine the "canonical path" of an existing file system
> object identified via some path name
> I think the question for about the first issue, ie, it was about a
> syntactical transformation. It's possible to come up with an algorithm
> for doing this.


The question was about Unix path names. The OP did not use the
phrase "syntactically redundant". It's quite possible that the
OP mistakenly thought that /../ is syntactically redundant, but in
fact it is not, and the OP needs to be made aware of that. (On the
other hand, // can be reduced to / in almost all cases, though I've
seen systems where a leading // has some special meaning.)

If the OP had specifically asked how to reduce, for example,
"aa/bb/../cc" to "aa/cc" considering only the syntax, that would
also be a reasonable question -- but that's not a particularly
useful transformation in the context of Unix path names, which is
what the OP asked about.

> If the question was really about the second issue, this answer is "this
> is impossible" --- whatever value an algorithm pretending to answer it
> returns may be entirely wrong by the time the caller acquires the output
> (TOCTOU-race) and consequently, the proper answer is not "download x *
> 1000 lines of random Perl code from a web server" but "As this cannot be
> done, try to solve your problem without it".


That's a good thing to warn the OP about, but the problem of reducing

aa/bb/cc/dd/../../ee/ff/gg/hh/../../../jj/kk/../nn/xyz.h

to a path not containing /../ to a path that refers to the same
file *at the time it's checked* is useful enough that there are a
number of existing solutions. See the documentation for Perl's
Cwd::abs_path (aliased as realpath) and File::Spec->canonpath,
and the POSIX realpath() function.

Sure, there's a risk that some symlink may be changed between
determining the path and using it, just as there's a risk that
anything else might be changed, but often that's an acceptable risk.
You could also worry that someone might edit xyz.h by inserting
malicious code.
Rainer Weikusat (11-19-19, 09:57 PM)
Keith Thompson <kst-u> writes:
> Rainer Weikusat <rweikusat> writes:
> [...]
> The question was about Unix path names.


Exactly. And "Unix path names" are an abstract concept not tied to any
specific filesystem and/or object which exists in a specific filesystem
namespace.

[...]

> That's a good thing to warn the OP about, but the problem of reducing
> aa/bb/cc/dd/../../ee/ff/gg/hh/../../../jj/kk/../nn/xyz.h
> to a path not containing /../ to a path that refers to the same
> file *at the time it's checked* is useful enough that there are a
> number of existing solutions.


The value returned by such a "solution" cannot safely be used for
anything because it might already have become invalid while some
components were still being checked.
Keith Thompson (11-20-19, 06:52 AM)
Rainer Weikusat <rweikusat> writes:
> Keith Thompson <kst-u> writes: [...]
>> The question was about Unix path names.

> Exactly. And "Unix path names" are an abstract concept not tied to any
> specific filesystem and/or object which exists in a specific filesystem
> namespace.


Does this abstraction insist that "aa/bb/../cc" is necessarily
equivalent to "aa/cc"? If so, it's not a very useful one.

[...]
> The value returned by such a "solution" cannot safely be used for
> anything because it might already have become invalid while some
> components were still being checked.


In that sense, no Unix path name can safely be used for anything, and
this whole exercise is pointless. You don't know that aa refers to the
same thing now that it referred to a moment ago.

And yet this kind of transformation is considered useful. Or do you
think the POSIX realpath() function is useless?
Rainer Weikusat (11-20-19, 04:42 PM)
Keith Thompson <kst-u> writes:
> Rainer Weikusat <rweikusat> writes:
> [...]
> Does this abstraction insist that "aa/bb/../cc" is necessarily
> equivalent to "aa/cc"? If so, it's not a very useful one.


This 'discussion' is not very useful and attaching it to a posting which
was originally about an algorithm for performing a syntactic
transformation is still completely out of place.
Keith Thompson (11-20-19, 07:07 PM)
Rainer Weikusat <rweikusat> writes:
> Keith Thompson <kst-u> writes:
> This 'discussion' is not very useful and attaching it to a posting which
> was originally about an algorithm for performing a syntactic
> transformation is still completely out of place.


The original question was not about "performing a syntactic
transformation". The question was about normalizing Unix path names
(the OP didn't use the word "normalizing", but that was the gist).
The OP *incorrectly* (but understandably) suggested a syntactic
transformation as a solution.

Your position seems to be that discussing the reasons a purely
syntactic transformation doesn't solve the OP's problem is
inappropriate. I strongly disagree. (And I don't think there's
anything more to say.)
Rainer Weikusat (11-20-19, 07:40 PM)
Keith Thompson <kst-u> writes:
> Rainer Weikusat <rweikusat> writes:
> The original question was not about


As I already wrote: This terror marketing of CPAN hacks hacking
around technically obsolete and deficient BSD file system hacks in order
to pretend to solve an unsolvable problem has no relation
to either the original text,

,----
| Hi all,
| Unix filenames such as
|
| aa/bb/cc/dd/../../ee/ff/gg/hh/../../../jj/kk/../nn/xyz.h
|
| appear in build dependencies.
|
| How do I reduce it to a proper filename?
|
| e.g.
| s|/\S+?/\.\.|/|g
`----

or my original posting.

Please feel free to believe otherwise but please stop randomly tacking
you texts onto my postings.
Eli the Bearded (11-20-19, 10:26 PM)
In comp.lang.perl.misc, Rainer Weikusat <rweikusat> wrote:
> As I already wrote: This terror marketing of CPAN hacks hacking
> around technically obsolete and deficient BSD file system hacks in order
> to pretend to solve an unsolvable problem has no relation
> to either the original text,
> ,----
> | Hi all,
> | Unix filenames such as
> |
> | aa/bb/cc/dd/../../ee/ff/gg/hh/../../../jj/kk/../nn/xyz.h ....
> | How do I reduce it to a proper filename?


Fundamentally, I belive this discussion has devolved into how Keith and
I both interpret that request for a "proper" "reduc[tion]" in
fundamentally different ways than you. That's why he and I have both
been replying specifically to you.

> Please feel free to believe otherwise but please stop randomly tacking
> you texts onto my postings.


It's not at all "randomly".

Elijah
------
expects he will post no more in reply to Rainer

Similar Threads