Hi Anthony, I think that all of the new functions that you introduced are correct in doing what they say (named), so I don't think we should change any of that. SFDIR as a concept I have always thought as a bit strange but useful in certain situations. I think it's alright as it is now in CVS, either you set SFDIR and everything goes there, or you don't set it and everything works like a normal commandline. So, I'm fine with it, and it seems everyone on the dev list is fine with it, but I have no idea if any of the users on the main list would have issues. I would venture to guess not, but don't know. If there is a clamor to change that behavior, I think the fix should just go in the FindOutputFile function (or whatever that's named) and do an extra check to see if a file has . or .. prepended to it, but not to change any of the functions you've done as they are quite clear. steven On 10/31/06, Anthony Kozar wrote: > Sorry about the unannounced change in behavior. I actually had not > considered the situation that you brought up. When I was rewriting the > code, I was mostly thinking about reading files, not writing them. > > And that really points to one of the major issues here: reading vs. > writing. When reading a file, Csound always checks the current directory > first. So "-i ./input.wav" or "-i input.wav" will read from the current > directory if it finds the file. If the pathname is absolute and the file is > not found, then Csound stops looking for it at this point. The former > behavior treated "./input.wav" as an absolute pathname, and thus would not > search SSDIR and SFDIR. But "input.wav" was a relative path and would > invoke searching the environment paths. The new behavior treats both as > relative and thus always searches the environment paths after the current > directory. For reading files, this is not so much a "change" in behavior as > an "enhancement." > > The potential confusion is with writing files, as you discovered. If the > pathname is absolute, only the current directory is tried. But for relative > paths, Csound always tries the environment paths first, and only tries the > current directory as a last resort. So changing the definition of an > "absolute path" had a significant effect here. > > The other major issue is of course the GUI mindset vs. shell mindset. I > have approached the problem from a GUI standpoint, where the current > directory is mostly irrelevant. But I see now that this may lead to > unintuitive results for the shell user. However, as you point out, there is > the issue of whether "-o ./test.wav" typed at the commandline should behave > differently than when it is in CsOptions. For the GUI user who downloads > someone else's CSD, the output file should probably go into the CSD > directory if SFDIR is not set. (Note though that it currently will _not_ do > this unless the GUI chdirs to that directory anyways -- this was another > problem that has not been "fixed" yet). > > I am not a Unix guru. Therefore I may not be the best person to decide > whether "./filename" should work differently than "filename" from the shell. > We could change "./" back to being treated as absolute. However, I think it > would be a mistake to change "../" back to being absolute. The question > then is whether this is too confusing. Also, there is no way on MacOS 9 to > distinguish between two Unix-style paths like this: "./dir/filename" and > "dir/filename". Both these would have to be converted to ":dir:filename" > and be interpreted the same. (This would not really be a problem -- it is > probably preferred -- but the behavior between OS 9 and other platforms > would then be subtlely different). > > The only precedent that I can think of on Unix for treating name and ./name > differently is how the shell finds executables. "csound" searches the $PATH > variable of course while "./csound" does not. This is similar to the old > Csound behavior for -o. But I am not aware of any precedents for processing > _arguments_ to commandline programs in this way. How does GCC do it? > Anyone else have any comments on this? > > Another solution would be to view the commandline version of Csound as "just > a front end that runs in the shell." Just as a GUI front end is responsible > for maintaining appropriate behavior, it could be the responsibility of the > commandline front end to maintain proper "shell behavior." So csound_main.c > could perform preprocessing on its arguments and expand "./" (and possibly > "../") to full pathnames. This would create different behavior for > commandline args and CsOptions (and .csoundrc) args however. > > *shrug* > > The current behavior suits me, but I don't really use the commandline. So I > am interested to hear what other people think. I do hope that we will > continue to be able to treat "./" and "../" at the beginning of pathnames as > relative when those pathnames are found as #includes or parameters within > the orchestra and score. (The commandline behavior and CsOptions behavior > is less important to me, and could be reasonably changed IMO). > > Sorry this is so long ... just wanted to make sure that everyone fully > understood the old vs. new behavior and the consequences of making further > changes. > > Thanks. > > Anthony Kozar > anthonykozar AT sbcglobal DOT net > > > Steven Yi wrote on 10/31/06 5:43 AM: > > > I think you make good points but this is also a change of behavior > > that hasn't thus far been noted. But you're right in this is a bit > > confusing. The usage I was accustomed to before was having SFDIR as a > > fallback, the default place to put things, but if I wanted to quickly > > test a CSD, then I would use "./test.wav" as my output and put it into > > the current directory. A handy feature for me, but I do agree that > > SFDIR then is pretty ambiguous as are paths in CsOptions, and that it > > is strange to type something like "csound test.csd -o test.wav" and > > have that output in SFDIR, while "csound test.csd -o ./test.wav" would > > output in the current working directory. > > > > I did like how it worked, but I guess I can get used to this. (Will > > probably just stop using SFDIR). > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net