New answers tagged

0

Following this link solves my problem : sudo localectl set-locale LANG=en_CA.UTF-8 # or change to en_US.UTF-8 depends on your locale-gen it generates a file /etc/locale.conf that fixes this issue


0

Following this link solves my problem: sudo localectl set-locale LANG=en_CA.UTF-8 # or change to en_US.UTF-8 depends on your locale-gen it generates a file /etc/locale.conf that fixes this issue


10

You can use the shell's sort order instead (which may not involve the locale's collation order; bash, AT&T ksh, yash, tcsh and zsh give the expected results, mksh and dash don't. fish seems to give a case insensitive order but gives different results when there are non-ASCII characters): ls -dUl -- .* * This gives ls an explicit list of files (and ...


4

You might simply use two separate ls commands: $ ls -dl ..?* .[^.]* 2>/dev/null ; ls -dl * -rw-r--r--. 1 sparhawk sparhawk 0 8 Jun 09:29 .a -rw-r--r--. 1 sparhawk sparhawk 0 8 Jun 09:29 .b -rw-r--r--. 1 sparhawk sparhawk 0 8 Jun 09:29 a -rw-r--r--. 1 sparhawk sparhawk 0 8 Jun 09:29 A -rw-r--r--. 1 sparhawk sparhawk 0 8 Jun 09:29 b -rw-r--r--. 1 ...


-2

You can play with ls command options. Try this: # ls -laXr Where: -l use a long listing format -a, --all do not ignore entries starting with . -X sort alphabetically by entry extension -r, --reverse reverse order while sorting


0

It looks like this is an incompatibility between HFS+ and linux as far as how the filesystems handle these special characters. Some more details here: "Re: File name encoding bug on HFS+ filesystem on Linux?? The problem is still here, and very frustrating. This seems to be an issue with any Linux distribution and Mac OS X. Any file created with Korean ...



Top 50 recent answers are included