Bug 67621 - mappedresources strips paths
Summary: mappedresources strips paths
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-05 23:40 UTC by David St. Denis
Modified: 2023-10-06 20:38 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David St. Denis 2023-10-05 23:40:35 UTC
<project>

    <property environment="env" />
    <first id="findcmd">
        <restrict>
            <mappedresources id="paths">
                <path path="${env.PATH}" />
                <filtermapper>
                    <suffixlines suffix="/find" />
                </filtermapper>
            </mappedresources>
            <exists/>
        </restrict>
    </first>

    <echo>
        ${toString:paths}
        ${toString:findcmd}
    </echo>
</project>

     [echo]         bin/find:bin/find:bin/find:sbin/find:sbin/find:bin/find:bin/find:bin/find:lnx64/find:unx/find:bin/find:lnx64/find:bin/find
     [echo]         bin/find

My expectation of the refid "paths" from the mappedresources would be to get "full" paths with /find added, not all the paths cut-off at the basename. Is this a really a bug?

Note: the first/restricts/exists part is my next step in trying to find find :), but the exists on the mappedresources is kind of meaningless as it doesn't appear to be treating these resources as actual paths.

Maybe my trouble is in not fully understanding this confusing documentation... "Even if mappedresources wraps a resource collection that consists of file-system based resources, mappedresources will not appear to be file-system based. This means you can't use mappedresources with tasks that only allow file-system based resources."  

Thanks.
Comment 1 Stefan Bodewig 2023-10-06 16:02:27 UTC
mappedresources is doing something quite different from what you expect it to do.

What it really does is it returns the very same resources that have been part of the resource collection wrapped (the directories contained in your PATH) and only act as if their name was different. But something like <exists> would still look at the directories and just tell you whether the directory exists, not if it contains find.

That the mapper is applied to the base name of the directory that is part of the PATH rather than the absolute path is something that surprises myself today - but likely has been the logical choice a long time ago.

Do you really need to find the find command or is it enough to know whether find is on your PATH so you can execute t? In the latter case

<available property="find.found" file="find" filepath="{env.PATH}"/>

would work,
Comment 2 Stefan Bodewig 2023-10-06 16:16:40 UTC
    <property environment="env" />
    <pathconvert pathsep="," property="pathdirs">
      <path path="${env.PATH}"/>
    </pathconvert>
    <first id="findcmd">
      <restrict id="r">
        <multirootfileset basedirs="${pathdirs}">
          <include name="find"/>
        </multirootfileset>
        <exists/>
      </restrict>
    </first>
    <echo>
        ${toString:findcmd}
    </echo>

does what you initially wanted
Comment 3 David St. Denis 2023-10-06 20:38:35 UTC
This was really going to be a generic routine wrapped in macrodef for finding any given file using any path. Useful for finding data in a sparsely populated environment we have.  I have a version where I also used multirootfileset in a similar way as well. Just wasn't 100% sure about the guarantee of order in searching the basedirs. 

I also had a version using whichresource, but shaving off the file:/ uri for windows and unix was not much fun.