On Tue, Oct 28, 2008 at 10:44:19PM +0800, changqin_gang wrote:
> When I remove the file at my sFtp server, there's some strange errors:
> the file "1.txt" located at "sftp://192.168.1.166/home/user/path/1.txt",if
> I set "sftp://192.168.1.166/home/user/" as url,and "rm path/1.txt" as
> command,it worked,however,using "sftp://192.168.1.166/home/user/path/" as url
> and "rm 1.txt" as command,it ended with an error:no such file or directory!
>
> why?

What seems to be happening is that path names given to the rm command (and
presumably, all the other sftp quote commands) is relative to the user's
home directory. So "rm 1.txt" is the same as "rm ~/1.txt" if given from a
command shell. If you set "sftp://192.168.1.166/some/random/path" as the
URL and "rm path/1.txt" as the command, it will also delete the same file
/home/user/path/1.txt--the URL is ignored in the quote command.

That violates the principle of least astonishment, so I think curl
ought to try to fix it. curl maintains a concept of a current working
directory so it should be able to prepend that to any quote command's file
name argument. But can it do that portably, for any remote SFTP server?
Including Windows (which uses a backslash directory separator) and every
other oddball operating system out there? Someone would have to verify that
before we consider making this change. It's also a major change in behaviour
that may break existing user applications.

On a side note, you can specify the home directory in the URL like this:
"sftp://192.168.1.166/~/path/1.txt". That will insulate your script from
potential changes to the absolute location of the home directory.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved