[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() {
- 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

I won't go into the second example. It is a variation on the same theme.


More information about the Swift-user mailing list