groost
July 12th, 2014, 05:44 PM
Last week I did a fresh install of 14.04 over an existing (special real-time copy of) 10.04 (necessary to run LinuxCNC), keeping the existing /home partition and combining separate /, /usr, and /var partitions into a single / 9GB-ish partition formatted for ext4 filesystem, as is home.
I have been surprised by the unexpected behavior of SHELL BUILTIN COMMANDS in bash, which now DO NOT respect the uppercase or lowercase of filenames.
% mkdir test
% cd test
% touch A.file x.file Z.file
% echo [A-Z]*
A.file x.file Z.file
But note:
% echo [X]*
X*
does NOT include x.file... :confused:
(It may not be a matter of 'case insensitivity' but one of [A-Z] including 'x' somehow.)
My first introduction to this changed behavior from 10.04 :( came by way of a
% rm [A-Z]*
which took out [a-z]* along with it...
I've looked at quite a few things:
% mv ~/.bashrc ~/.bashrcRENAMED
% sudo /etc/bash.bashrc /etc/bash.bashrcRENAMED
% shopt | grep case
nocaseglob off
nocasematch off
% echo set completion-ignore-case Off >> ~/.inputrc
% which rm [ls|echo]
/bin/rm [ls|echo]
% bash
with no change in behavior. I copied the test dir to the home partition (also ext4) and observed the same behavior.
I did find one interesting thing: the _longopt() function(?) which is visible from the set command:
% set | less
in the definition of which I find this entry, which I do not pretend to understand, nor even to recognize as germane, but which strikes me as "unbalanced" because it has 'A-Z' on one side and not the other:
_longopt ()
{
local cur prev words cword split;
_init_completion -s || return;
case "${prev,,}" in
--help | --usage | --version)
return 0
;;
--*dir*)
_filedir -d;
return 0
;;
--*file* | --*path*)
_filedir;
return 0
;;
--+([-a-z0-9_]))
local argtype=$( $1 --help 2>&1 | sed -ne "s|.*$prev\[\{0,1\}=[<[]\{0,1\}\([-A-Za-z0-9_]\{1,\}\).*|\1|p" );
case ${argtype,,} in
*dir*)
_filedir -d;
return 0
;;
*file* | *path*)
_filedir;
return 0
;;
esac
;;
esac;
I've been over my head in Linux many times in my 22 or so years using it, but I'm going to need decompression after this dive.
What, oh tell, do!, could be the cause? Or what further investigations I might make?
Thank you for your thoughts on 't.
I have been surprised by the unexpected behavior of SHELL BUILTIN COMMANDS in bash, which now DO NOT respect the uppercase or lowercase of filenames.
% mkdir test
% cd test
% touch A.file x.file Z.file
% echo [A-Z]*
A.file x.file Z.file
But note:
% echo [X]*
X*
does NOT include x.file... :confused:
(It may not be a matter of 'case insensitivity' but one of [A-Z] including 'x' somehow.)
My first introduction to this changed behavior from 10.04 :( came by way of a
% rm [A-Z]*
which took out [a-z]* along with it...
I've looked at quite a few things:
% mv ~/.bashrc ~/.bashrcRENAMED
% sudo /etc/bash.bashrc /etc/bash.bashrcRENAMED
% shopt | grep case
nocaseglob off
nocasematch off
% echo set completion-ignore-case Off >> ~/.inputrc
% which rm [ls|echo]
/bin/rm [ls|echo]
% bash
with no change in behavior. I copied the test dir to the home partition (also ext4) and observed the same behavior.
I did find one interesting thing: the _longopt() function(?) which is visible from the set command:
% set | less
in the definition of which I find this entry, which I do not pretend to understand, nor even to recognize as germane, but which strikes me as "unbalanced" because it has 'A-Z' on one side and not the other:
_longopt ()
{
local cur prev words cword split;
_init_completion -s || return;
case "${prev,,}" in
--help | --usage | --version)
return 0
;;
--*dir*)
_filedir -d;
return 0
;;
--*file* | --*path*)
_filedir;
return 0
;;
--+([-a-z0-9_]))
local argtype=$( $1 --help 2>&1 | sed -ne "s|.*$prev\[\{0,1\}=[<[]\{0,1\}\([-A-Za-z0-9_]\{1,\}\).*|\1|p" );
case ${argtype,,} in
*dir*)
_filedir -d;
return 0
;;
*file* | *path*)
_filedir;
return 0
;;
esac
;;
esac;
I've been over my head in Linux many times in my 22 or so years using it, but I'm going to need decompression after this dive.
What, oh tell, do!, could be the cause? Or what further investigations I might make?
Thank you for your thoughts on 't.