Well, it depends on whether you think that is a bug.

The problem is what to do when we encounter paths beginning with "./" or
../" in a CSD and there is no "reasonable" concept of a current directory.
Any GUI front end started by double-clicking falls into this category in my
opinion.  And I think paths like this should be interpreted relative to the
appropriate search paths.  That is why I changed the function that
determines whether a pathname is absolute or not.

I wasn't really sure when I changed the code if the shell would expand ./ or
not.  But if you think that pathnames beginning with "./" typed in on the
commandline should be interpreted as the shell would interpret them, then I
think we will have difficulty distinguishing between them and those that
were read from an input file.  Plus, I am not sure that having different
behavior depending on the source of the pathname makes sense.

Besides, if you've gone to the "trouble" of setting SFDIR, then I don't
think the output should go to the current directory.  Setting SFDIR, IMHO,
means that the name of the output file will be interpreted relative to
SFDIR.

Anthony


Steven Yi wrote on 10/30/06 11:13 AM:

> Hi Anthony and all,
> 
> I think one of the directory handling changes that happened in
> envvar.c did introduce a bug, and I want to say it has to do with code
> that did assume paths given "./" or "../" or the like were absolute.
> What I'm experiencing is if I do something like:
> 
> csound examples/xanadu.csd -o ./test.wav
> 
> The wav file does not get generated in the cwd, but rather in SFDIR.
> 
> I've taken a look to find out what's going on but haven't quite found
> it yet.  Any suggestions?


-------------------------------------------------------------------------
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

given the new system of defaults, which I am loving, i am relying on  
SFDIR much
less and the system, on a variety of platforms, is working much more  
intuitively and
more out of the box.

-dB

On Oct 31, 2006, at 5:43 AM, Steven Yi wrote:

> Hi Anthony,
>
> 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).
>
> Thanks for the reply!
> steven
>
>
> On 10/31/06, Anthony Kozar  wrote:
>> Well, it depends on whether you think that is a bug.
>>
>> The problem is what to do when we encounter paths beginning with  
>> "./" or
>> ../" in a CSD and there is no "reasonable" concept of a current  
>> directory.
>> Any GUI front end started by double-clicking falls into this  
>> category in my
>> opinion.  And I think paths like this should be interpreted  
>> relative to the
>> appropriate search paths.  That is why I changed the function that
>> determines whether a pathname is absolute or not.
>>
>> I wasn't really sure when I changed the code if the shell would  
>> expand ./ or
>> not.  But if you think that pathnames beginning with "./" typed in  
>> on the
>> commandline should be interpreted as the shell would interpret  
>> them, then I
>> think we will have difficulty distinguishing between them and  
>> those that
>> were read from an input file.  Plus, I am not sure that having  
>> different
>> behavior depending on the source of the pathname makes sense.
>>
>> Besides, if you've gone to the "trouble" of setting SFDIR, then I  
>> don't
>> think the output should go to the current directory.  Setting  
>> SFDIR, IMHO,
>> means that the name of the output file will be interpreted  
>> relative to
>> SFDIR.
>>
>> Anthony
>>
>>
>> Steven Yi wrote on 10/30/06 11:13 AM:
>>
>>> Hi Anthony and all,
>>>
>>> I think one of the directory handling changes that happened in
>>> envvar.c did introduce a bug, and I want to say it has to do with  
>>> code
>>> that did assume paths given "./" or "../" or the like were absolute.
>>> What I'm experiencing is if I do something like:
>>>
>>> csound examples/xanadu.csd -o ./test.wav
>>>
>>> The wav file does not get generated in the cwd, but rather in SFDIR.
>>>
>>> I've taken a look to find out what's going on but haven't quite  
>>> found
>>> it yet.  Any suggestions?
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> 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
> 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

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

Very well.  I will not change anything for now.  I had kind of expected much
more resistance on this issue, but either I have been more persuasive than I
expected or everyone is at ICMC and not paying attention this week ^_^

I did find the following paragraph in the manual under the analysis
utilities.  It will probably have to be changed (?).

"Filenames are of two kinds, source soundfiles and resultant analysis files.
Each has a hierarchical naming convention, influenced by the directory from
which the Utility is invoked. Source soundfiles with a full pathname (begins
with dot (.), slash (/), or for ThinkC includes a colon (:)), will be sought
only in the directory named. Soundfiles without a path will be sought first
in the current directory, then in the directory named by the SSDIR
environment variable (if defined), then in the directory named by SFDIR. An
unsuccessful search will return a "cannot open" error."

Thanks Steven.

Anthony

Steven Yi wrote on 11/2/06 5:19 AM:

> 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.


-------------------------------------------------------------------------
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