[9fans] rc and spaces in file names
Hello,
I usually edit file names with a 'for' statement, so i can replace
spaces and other problematic characters without effort. But today
I needed to change names keeping spaces and I found something weird.
Let be two files: 'Plan 9' and 'Plan B'. In a korn or bourne shell I
can do something like:
$ for i in Plan*; do a=`echo $i | 9 sed s'/lan/LAN/g'`; cp $i $a;
done
without problems with spaces. In Plan9 I've tried
term% ifs='\n' for(i in Plan*){cp $i `{echo $i | sed 's/lan/LAN/'}}
cp: can't create PLAN 9
: bad character in file name: 'PLAN 9
'
cp: can't create PLAN B
: bad character in file name: 'PLAN B
'
'
So the last newline character is added to the file name...
I tried typing a literal newline in the ifs variable and it works:
term% ifs='
' for(i in Plan*){cp $i `{echo $i | sed 's/lan/LAN/'}}
term% ls P*
'PLAN 9'
'PLAN B'
'Plan 9'
'Plan B'
With p9p is the same. I'll appreciate If anyone can tell me why.
trebol.
Re: [9fans] rc and spaces in file names
term% ifs='\n' for(i in Plan*){cp $i `{echo $i | sed 's/lan/LAN/'}}
cp: can't create PLAN 9
: bad character in file name: 'PLAN 9
'
cp: can't create PLAN B
: bad character in file name: 'PLAN B
'
'
So the last newline character is added to the file name...
I tried typing a literal newline in the ifs variable and it works:
term% ifs='
' for(i in Plan*){cp $i `{echo $i | sed 's/lan/LAN/'}}
term% ls P*
'PLAN 9'
'PLAN B'
'Plan 9'
'Plan B'
With p9p is the same. I'll appreciate If anyone can tell me why.
rc doesn't do backslash escapes.
tristan
--
All original matter is hereby placed immediately under the public domain.
Re: [9fans] rc and spaces in file names
I tried typing a literal newline in the ifs variable and it works:
term% ifs='
' for(i in Plan*){cp $i `{echo $i | sed 's/lan/LAN/'}}
term% ls P*
'PLAN 9'
'PLAN B'
'Plan 9'
'Plan B'
With p9p is the same. I'll appreciate If anyone can tell me why.
i'm not sure which question you have. i'll try to answer the two i see.
'\n' doesn't work because rc doesn't interpret \ except as the last character
of a line. plan 9 ls helpfully quotes file names that might need quoting
if fed to rc. ls -Q will get rid of the quotes. (see ls(1).) so the file names
do not include the single quotes. if they did, you'd see '''Plan B'''.
- erik
[9fans] rc and spaces in file names
Ok, thanks to both. I got confused with this part of rc(1):
`{command}
rc executes the command and reads its standard output,
splitting it into a list of arguments, using characters
in $ifs as separators. If $ifs is not otherwise set,
its value is ' \t\n'.
Re: [9fans] rc and spaces in file names
On Fri Dec 20 09:48:29 EST 2013, trebol55...@aol.com wrote:
Ok, thanks to both. I got confused with this part of rc(1):
`{command}
rc executes the command and reads its standard output,
splitting it into a list of arguments, using characters
in $ifs as separators. If $ifs is not otherwise set,
its value is ' \t\n'.
that's a good point. it looks like the wrong conventions were applied
to that string. ironically, one would guess, this was to solve a
readability problem. perhaps ... otherwise set, space, newline, tab will
be used as separators would be more precice even if it doesn't read
as well.
- erik
Re: [9fans] mk time-check/slice issue
The problem discussed here is caused by low-resolution timestamps. The solution is to to increase the resolution of the timestamps, not to add hacks to the mk tool. Adding hacks and special casings inside tools is one of the main reasons why Unix is so clumsy and hard to use. Look at how networking was added to BSD. A quick hack to the kernel that expanded the API surface and required writing new programs. On Plan 9 we know better. Increasing timestamp resolution comes at a cost. It is a problem too minor to be addressed on its own. If there's ever a revamp of the protocols for some other, more fundamental reason, perhaps it is worth addressing. Perhaps not. See IX. Making lasting changes too early is also a mistake Unix made. I'd also like to note that if low-resolution timestamps became observable in mk, the thing you are building compiles so quickly that it's unlikey to cause any wasted human time. Avoiding solving problems that exist only as academic exercises to keep complexity down is also one good trait of Plan 9. -- Aram Hăvărneanu
[9fans] ahci 1.3.1
does anyone on the list have an ahci device that supports version 1.3.1? you can find this information in /dev/sdctl. here's mine: sdE ahci ahci port 0xfe00fe33b800: 64a ncq alp led clo pmb slum pslum iss 2 ncs 31 np 4 ghc 8002 isr 0 pi f 0-3 ver 10100 the ver would be 30101. i'd like to figure out if this just works, or if some tweaking is required from 1.3. - erik
[9fans] New release of Dynace on Plan-9
Greetings, I have released a refreshed port to Plan-9 of my Dynace OO extension to C. This is open-source. Dynace adds advanced OO capabilities to C including a metaobject protocol, multiple inheritance, generic functions and much more. In Dynace, classes are first class objects. Each class has another class that defines it - its metaclass - just like Smalltalk and CLOS. Dynace also has generic functions and cached dynamic dispatching like Common Lisp's CLOS. Dynace includes an extensive class library. It also comes with a complete GUI development environment (that portion only runs under Windows or Linux/Mac/BSD/etc. through Wine). Dynace is extensively documented with two included 300+ page books and a tutorial. Dynace is portable to 32 64 bit Plan-9, Linux, BSD, Mac, Windows DOS. You can download the entire source from: http://blake.mcbride.name/software/dynace Blake McBride (P.S. please make sure you get release 20131220 - in case you are seeing an old, cached web page.)
