rmate fails, when ls gives filesize containing ,

[NoNoNo]

My version of ls is outdated (can’t do anything about that…):

$ ls --version
ls (GNU coreutils) 5.97

rmate in line 295 says:

filesize=`ls -lLn "$realpath" | awk '{print $5}'`

The result with my version of ls is for example 12,345. Then rmate fails by displaying only the N bytes of the number before the , – 12 in this example.

I fixed this by adding the following line after 295:

filesize=$(echo "$filesize" | sed 's/,//')

[aurora]

Thanks for reporting this issue. I have to admit, that i didn't test this on older systems for quite a while now, even though it was the original intent to target older systems. Will delve into this issue next year ;).

[aurora]

I am not sure, if this has something todo with the version of ls, at least i was not able to dig anything up regarding gnu ls and this kind of numeric formatting. The closest thing i found was someone who defined an alias for ls in the form of alias ls="ls --block-size=\'1" which leads to human readable output when using ls -l. Could you please enter the following in a shell of the system and tell me the output?

type ls

Thanks!

[NoNoNo]

$ type ls
ls is an alias for ls --color=yes -F
ls is /bin/ls

[aurora]

Ah ... so the alias i found was overcomplicated. Your alias does this as well, if you list a directory by executing /bin/ls -l directly, the output should be normal (non numeric formatting). Interesting. I wonder where this alias get's defined on your system, because normally rmate shouldn't pick this up. I have to think about what's the best way to solve this issue.

[aurora]

This should work now on your system, can you try it and give feedback? Thanks!

[NoNoNo]

Works! Thank you!