- removed comment
GetComponents modifies its passed in thornlist file
It seems to add
# This file was automatically generated using the GetComponents script.
even if the file passed in is a file on the local file system and a URL on the network.
It should not do this.
Keyword:
Comments (8)
-
reporter -
- removed comment
The main reason this is there is that GetComponents understands includes in thornlists, and those could very well be in a local file or downloaded. Another possibility is giving GetComponents multiple targets to work on - which will concatenate the thornlists into one. In order to remove that comment, one would need to make sure none of these things actually happened.
-
reporter - removed comment
Well, this is of course my personal preference, but I think it should just never modify its inputs. It already writes a .crl_components file and I would think that is sufficient.
-
- removed comment
Oh, it shouldn't modify it's inputs. It reads a file and, if specified in the thornlist itself, writes a new list to the filename that was specified. Those are usually not the same files - although they could be I suppose. But then it was the user specifying input and output file being the same, wasn't it?
-
- removed comment
Replying to [comment:4 knarf]:
Oh, it shouldn't modify it's inputs. It reads a file and, if specified in the thornlist itself, writes a new list to the filename that was specified. Those are usually not the same files - although they could be I suppose. But then it was the user specifying input and output file being the same, wasn't it?
To give an example:
./repos/CRL/GetComponents ./manifest/einsteintoolkit.th
would (should), given a standard ET thornlist, read ./manifest/einsteintoolkit.th and write ./thornlists/einsteintoolkit.th . Do you see something else?
-
reporter - removed comment
Ah, let me see. I was modifying the file I had passed on the command line, however that file (a copy of einsteintoolkit.th in thornlists) contained
!DEFINE COMPONENTLIST_TARGET = $ROOT/thornlists/
which I guess causes GetComponents to overwrite its input when used as
bin/GetComponents --root . thornlists/bnscomparison.th
I would say it behaves as expected, I just did not know it was that powerful. It may require documentation. I think this ticket can be closed as "wontfix" since it does what it is supposed to do.
-
reporter - changed status to resolved
- removed comment
User error: I had not realized that the thornlist itself was instructing GetComponents to write out a parsed version (and the path happened to be the original path of the file name).
-
reporter - changed status to closed
- edited description
- Log in to comment