I'm running on various flavors of Linux.
The conditional code for different OSes makes reading this code cold a
bit hairy, but given that info it's now fairly obvious where the issue
is. I may just be able to tweak the ls options to provide a more
unique separator.
I was just writing some shell script the other day where something
like "find -print0 | grep -zZ | xargs -0" was the key to dealing with
similar issues. Maybe the -b option to ls to escape the string, or -D
which gives offsets to the start and end of the names, or -Q to quote
the name, ...
On Sat, Apr 25, 2015 at 1:38 PM, John E. Davis <jed@xxxxxxxxxxx
<mailto:jed@xxxxxxxxxxx>> wrote:
Tom Culliton <tom.culliton@xxxxxxxxx
<mailto:tom.culliton@xxxxxxxxx>> wrote:
> I did a little poking around in dired.sl <http://dired.sl>
looking for obvious issues but
> nothing jumped out at me. Maybe it's an issue with
parse_filename, or the
> underlying slang functions?
No, the slang functions are ok. The problem is that the dired_point
function cannot handle filenames with spaces. Dired relies upon shell
functions such as "ls" on Unix and "dir" on DOS/Windows/VMS systems to
produce the directory listing that appears in the *dired* buffer.
The precise output of these commands is locale-dependent.
The dired_point function assumes that the name of the file is the last
whitespace delimited word on the line, which breaks if the filename
contains spaces.
The solution would be for me to rewrite the code that produces the
dired listing so that it does not depend upon "ls" or "dir".
What OS are you using?
Thanks,
--John
_______________________________________________
For list information, visit
<http://jedsoft.org/jed/mailinglists.html>.