[Swift-user] output file array
Mihael Hategan
hategan at mcs.anl.gov
Fri Jan 9 14:20:43 CST 2015
On Fri, 2015-01-09 at 13:17 -0600, Ketan Maheshwari wrote:
> >
> > I do not think that is true. Swift creates directory structures for all
> > input and output files, whether they are specified on the command line
> > or not. If this isn't working, then we are talking about a bug, but the
> > code was designed to do this from the start. I did a quick check and it
> > seems to work fine for both 0.95 and trunk.
> >
>
> May be it is a bug. See the attached tarball which have example cases of
> things that work and does not. touchafile1.swift illustrates this above
> point.
>
I think it works as expected.
You have an app that creates a file and you are specifying that swift
should stage out another file that doesn't exist.
I'll simplify this a bit, but this is essentially what your first
example does:
- the executable creates a file, "a.txt"
- you have the following swift code:
app (file outf) runapp() {
myapp;
}
- the following swift script works:
file outf <"a.txt">;
outf = runapp();
- the following swift script does not:
file outf <"dir/a.txt">;
outf = runapp();
The second version is not supposed to work. If you abstract away the
notion of directories and give no meaning to "/" as a path separator,
your second example is equivalent to saying:
file outf <"dir_a.txt">, whereas your application produces "a.txt".
In other words your application produces a file, "a.txt" and you are
asking swift to stage out a different file, and whether that is
"dir_a.txt" or "dir/a.txt" makes no difference.
So I think that we are setting up an artificially difficult situation
here and then ending up with long debates that get lost in the details.
So I suggest that you either change your app to accept file names for
outputs or wrap it into a shell script that does that. That wrapper can
be tested outside of swift and does not require exact matching like
above.
I won't go into the second example. It is a variation on the same theme.
Mihael
More information about the Swift-user
mailing list