aiuto!
Salve e` da pochissimo che uso la shell in Linux e ho caricato yakuake!!! Quando richiamo e scrivo una riga di comando tipo questa: bash-2.05b$ cd /mnt/usb mi risulta: bash-2.05b$: Qual`e' il comando che mi permette di sapere in che directory mi trovo??? Grazie mille. -- MANUEL - http://www.texastornado.it ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
Tim Waugh wrote: >> strcoll indicates that, in the "en_US" locale, `h' sorts between `A' and >> `Z'. In the "C" locale, it does not. This is consistent with the >> collating sequences I posted earlier. > > Here is what Ulrich Drepper has to say on the matter (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217359#c5): > > "[...] The strcoll result has nothing whatsoever to do with > the range match. strcoll uses collation weights, ranges use > collation sequence values, completely different concept. This is an academic distinction of little or no practical value. There is no portable interface that exposes the difference to the programmer. All there is is strcoll (which, for its part, says nothing about that). Posix says there is no difference: A collation sequence definition shall define the relative order between collating elements (characters and multi-character collating elements) in the locale. This order is expressed in terms of collation values; that is, by assigning each element one or more collation values (also known as collation weights). This implies to me that the collation weights are what determines the collation sequence order. Maybe that's why there is no Posix interface to expose the difference. > Not matching 'h' (note, lowercase) is correct since if you > look at the locale definition you'll see that first all > lower characters are described and then the uppercase. So > h is not in A-Z. H (uppercase) of course is. But that's the point: I can't "look at the locale definition." And there is no library function that will allow me to do so. I make do with what strcoll() gives me. > From all I can see so far it's entirely bash's fault by not > implementing globbing correctly. bash really must use the > fnmatch code from glibc itself." Why would I do that? That does nothing to enhance portability. I can put the old subtraction code in that ignores the locale myself, since, as far as I can tell, that's the only portable part of the glibc fnmatch code. It would be a step backward to ignore the locale information, though. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. No day but today. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: aiuto!
manuel targa wrote: > Qual`e' il comando che mi permette di sapere in che directory mi > trovo??? pwd Aŭ uzu: export PS1='\[\e[001;[EMAIL PROTECTED] \[\e[001;034m\]\w \$\[\e[000m\]' por ĉiam vidi kie vi estas. Benno ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: nocaseglob
On 2/16/07, Chet Ramey <[EMAIL PROTECTED]> wrote: Tim Waugh wrote: >> strcoll indicates that, in the "en_US" locale, `h' sorts between `A' and >> `Z'. In the "C" locale, it does not. This is consistent with the >> collating sequences I posted earlier. > > Here is what Ulrich Drepper has to say on the matter (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217359#c5): > > "[...] The strcoll result has nothing whatsoever to do with > the range match. strcoll uses collation weights, ranges use > collation sequence values, completely different concept. This is an academic distinction of little or no practical value. There is no portable interface that exposes the difference to the programmer. except ``ls [a-z]*'' In the absence of any locale specification (via LANG and LC_* environment variables), it is incomprehensible to claim that it is reasonable to include upper case letters in the range of matched characters using a range of lower case letters. Your quoted paragraph: A collation sequence definition shall define the relative order between collating elements (characters and multi-character collating elements) in the locale. This order is expressed in terms of collation values; that is, by assigning each element one or more collation values (also known as collation weights). This implies to me that the collation weights are what determines the collation sequence order. two points: 1. collation sequence is not the same as character range. [a-z] is a range. 2. there is no locale specified, so it must be the default. The default is C. not en_US or whatever. But that's the point: I can't "look at the locale definition." And there is no library function that will allow me to do so. I make do with what strcoll() gives me. bash should be entirely consistent with fnmatch. The best way to do that is to use fnmatch. Then, if there is a problem, we jump on Ulrich instead of you. :) > From all I can see so far it's entirely bash's fault by not > implementing globbing correctly. bash really must use the > fnmatch code from glibc itself." Why would I do that? That does nothing to enhance portability. Yes, it does. You can use the fnmatch module from gnulib to backfill where necessary. can put the old subtraction code in that ignores the locale myself, since, as far as I can tell, that's the only portable part of the glibc fnmatch code. It would be a step backward to ignore the locale information, though. It is a step forward to ignore locale information when there is no locale information, though. :-) Thanks - Bruce ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
