Re: "Unprintable" 8-bit characters
"Conrad J. Sabatier" wrote: > > > > Yes, and this is one area where the labels are more than a little > misleading as well. My natural inclination is think of UTF-8 as being a > single-byte representation for each character in the set, whereas > UTF-16, as the name implies, would be the "wide", 2-byte version. "Not exactly." > Nonetheless, as I posted earlier in this thread, according to the info > in gucharmap, the representations of the umlauted "u" are just the > opposite of this: "not exactly." Again. > UTF-8: 0xC3 0xBC > UTF-16: 0x00FC > > Go figure, huh? :-) In UTF-16, everything _is_ a 16-bit entity. Notice that 0x00FC has -four- nybbles after the '0x.' Every character boundary is on a multiple of 16 bits. In UTF-8, the 'base' charset -- the 'C0' and 'C1' groups are represented by a single byte. 'extended' characters are represented by two bytes. Thus, 'characters' have a *variable*length* representation -- one or two bytes. A character, whether it is represented by one or two bytes, can begin on -any- byte boundary within a data stream, depending on 'what came before it'. UTF-8 2-byte representations are designed such that one can jump to any _byte_ offset within the file, and determine -- by looking *only* at the value of that byte whether is is (a) a single-byte character, (b) the first byte of a two-byte sequence, or (c) the second byte of a two-byte sequence. With UTF-16 you can position directly to any -character-, by jumping to a _byte_ offset that is twice the index of the character you want. Given a byte offset, you always know the 'equivalent' _character_ offset. With UTF-8, you have to read the character stream, counting 'characters' as you go, to get to the desired point. You can seek to an arbitrary _byte_ offset, but you do not know how mny 'characters' into the file that offset is. UTF-8 vs. UTF-16 is a trade-off between 'compactness' (UTF-8), and simplicity of addessing/representation (UTF-16). > This seems rather unfortunate to me. You would think that, by now, > some "standard" character set might have emerged that would allow one > to use, at the very least, the "Western" characters (as opposed to > the "Eastern" or "Oriental" or "Asian", if you will) with a reasonable > expectation that others will see what was intended. Heh. How many 'character' codes are you willing to devote to national 'currency symbols', just for starters? Probable minimum of two per currency -- one for the minimum coinage unit (cent, pence, pfennig, etc.) and one for the denomination unit (dollar, pound, mark, kroner, etc.) Now, one (obviously) has to have the basic 'Roman' alphabet. Then there are all the diacritical markings (accent, accent grave, dot umlaut, ring, bar, 'hat', inverted hat, etc.) for vowels. And cedilla, tilde, etc., for select consonants. Plus language specific symbols like ess-zett , 'thorn', etc. How about phonetic symbols, like 'schwa' ? And Greek for all sorts of scientific use? What about Cyrilic characters, for many Eastern Eurpean languages? Now, consider punctuation marks: the 'typewriter' basics, How many of 'minus-sign, hyphen, em-dash, en-dash, soft-hyphen' are needed? How many of 'accent, accent grave, apostrophe, opening/closing single-quote' are needed? opening/closing double-quotes, and/or a 'position neutral' double-quote? "Other symbols", like -- digits, common fractions, 'Trademark','Registered trademark','copyright' 'paragraph','section', superscripts -- exponents, footnotes, etc. subscripts -- chemical formulae, etc. "Simple line-drawing graphics" Diphthongs?? Ligatures?? Start counting things up. An 8-bit 'address space' gets used used up _really_ quick. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Tue, 8 Nov 2011 20:24:18 -0600 "Conrad J. Sabatier" wrote: > Even more confusing, selecting the character and copying it to the > clipboard, the UTF-16 representation (0xfc) is what actually gets > used. Pasting this single-byte version into an X terminal (any of > them: xterm, gnome-terminal, etc.) does display the correct character, > an umlauted "u", even if using an 8-bit locale, such as UTF-8. > Majorly confusing! Just realized on reading this how weird it sounds. What I was getting at here was that the (single-byte) UTF-16 code displays the correct character in a UTF-8 locale, even though the UTF-8 code for the character is supposedly a 2-byte sequence. Anyway, enough about that. I've managed to get the results I was hoping for now, so I'm satisfied. :-) Thanks again for all the responses. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Tue, 08 Nov 2011 21:27:16 -0400 Daniel Staal wrote: > --As of November 8, 2011 7:58:04 PM -0600, Conrad J. Sabatier is > alleged to have said: > > > So, what would be the safest bet as far as the most "universal" > > representation for these characters? Something I've long wondered > > about when I've e-mailed people and copied/pasted these characters > > (are they really seeing what I'm seeing?). :-) > > --As for the rest, it is mine. > > These days, the safest bet is UTF-8, or some other Unicode character > set, in something that can convey what character set it is in. > (Email can, depending on the mail client.) > > Not that Unicode is universal yet, but it designed to be (and is, > generally) a solution to the 'multiple character encodings' problem. > (By, of course, defining a new encoding.) It has a decent amount of > traction, and in a decade or so - once other options have been firmly > depreciated - I'd expect we could start discussing whether to switch > ls to using it by default. ;) > > All this is of course if you *must* go beyond 7-bit ASCII. (Which > all forms of Unicode is designed to be a strict superset of.) That sounds sane and sensible. :-) I've adjusted my environment to include: export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8 And also adjusted my console configuration to display these characters: font8x14="iso-8x14" font8x16="iso-8x16" font8x8="iso-8x8" And, last but not least, aliased "ls" to ensure these characters will actually be displayed: alias ls='ls -Fw' Looking good here now: conrads:~$ cd "Music/Progressive Rock/Yes/The Yes Album" conrads:~/Music/Progressive Rock/Yes/The Yes Album$ ls *03* Yes - The Yes Album - 03 - Starship Trooper: a. Life Seeker - b. Disillusion - c. Würm.mp3 Many thanks to everyone for all the very helpful, useful information. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Wed, 9 Nov 2011 03:10:24 +0100
Polytropon wrote:
> On Wed, 09 Nov 2011 02:51:31 +0100, Michael Ross wrote:
> > Am 09.11.2011, 01:42 Uhr, schrieb Conrad J. Sabatier
> > :
[snip]
> > > I've been trying to understand what the deal is with regards to
> > > the displaying of the "extended" 8-bit character set, i.e., 8-bit
> > > characters with the MSB set.
[snip]
> > Unsure if I understand you correctly.
> > ("extended" 8-bit character set with MSB? utf-16?)
> > I'm confused by this charset stuff in general.
> >
> > Assuming you want \0xfc displayed as "ü",
[snip]
> > here is what works for me:
> >
> > in my login class in /etc/login.conf:
> >
> > :charset=ISO-8859-1:\
> > :lang=de_DE.ISO8859-1:\
> >
> > ``cap_mkdb /etc/login.conf'' after changes
>
> Ah, thanks - that seems to be the proper way to have
> the environmental variables set - instead of my (ab)use
> of setenv's in the csh config file. :-)
Same here. I've been "guilty" as well of neglecting to properly adjust
my console configuration.
> Note the "precedence" of $LANG vs. $LC_* (as they can
> be used to configure things more precisely, e. g.
> regarding system messages or date formats; see example
> following).
>
>
>
> > in /etc/rc.conf:
> >
> > scrnmap="iso-8859-1_to_cp437"
>
> Hm? CP437? Codepage? Isn't that some MS-DOS thing?
> I've never needed a screenmap to make "extended
> characters" (everything beyong US-ASCII) work.
>
>
>
> > font8x8="cp850-8x8"
> > font8x14="cp850-8x14"
> > font8x16="cp850-8x16"
> >
> >
> > and in /etc/ttys, console type is set to ``cons25l1''
>
> I have a similar setting here, but that does _not_ work
> wuth UTF-8 codec characters. If I want to use them, I
> have to change some environmental variables, from
>
> #---GERMAN/ENGLISH <=== DEFAULT
> setenv LC_ALL en_US.ISO8859-1
> setenv LC_MESSAGES en_US.ISO8859-1
> setenv LC_COLLATE de_DE.ISO8859-1
> setenv LC_CTYPEde_DE.ISO8859-1
> setenv LC_MONETARY de_DE.ISO8859-1
> setenv LC_NUMERIC de_DE.ISO8859-1
> setenv LC_TIME de_DE.ISO8859-1
> unsetenv LANG
>
> to
>
> #---INTERNATIONAL-
> setenv LC_ALL en_US.UTF-8
> setenv LC_MESSAGES en_US.UTF-8
> setenv LC_COLLATE de_DE.UTF-8
> setenv LC_CTYPEde_DE.UTF-8
> setenv LC_MONETARY de_DE.UTF-8
> setenv LC_NUMERIC de_DE.UTF-8
> setenv LC_TIME de_DE.UTF-8
> setenv LANGde_DE.UTF-8
Doesn't using "LC_ALL" obviate the need to set any of the other LC_*
variables? At least, that's always been my understanding of it.
But, getting back to something you said earlier, what did you mean
exactly about the precedence of LANG vs. LC_*?
> Then I can use UTF-8 characters inside rxvt-unicode. Of
> course, text mode console is limited to the first set
> of configuration, using the ISO 8859-1 character set.
>
> This worked long before UTF-8 arrived with the glorious
> idea that I should have 2 bytes where one is sufficient,
> to describe our (german) 6 umlauts and the Eszett ligature. :-)
Yes, and this is one area where the labels are more than a little
misleading as well. My natural inclination is think of UTF-8 as being a
single-byte representation for each character in the set, whereas
UTF-16, as the name implies, would be the "wide", 2-byte version.
Nonetheless, as I posted earlier in this thread, according to the info
in gucharmap, the representations of the umlauted "u" are just the
opposite of this:
UTF-8: 0xC3 0xBC
UTF-16: 0x00FC
Go figure, huh? :-)
> Improper settings will result in [][] or A-tilde three
> quarters upside-down question mark, depending on editor
> or terminal used.
Yes, I will definitely have to try using the recommendations that have
come up in this thread re: the console.
> But returning to the original question, I think Robert
> did explain it very well: There is no real consensus
> about what the different codings should mean. They
> were meant to unify the representation of a very large
> set of characters, but basically there are many inter-
> pretations now, and how they show up to the user depends
> on the font in use, _if_ it has this mapping or that,
> or none.
This seems rather unfortunate to me. You would think that, by now,
some "standard" character set might have emerged that would allow one
to use, at the very least, the "Western" characters (as opposed to
the "Eastern" or "Oriental" or "Asian", if you will) with a reasonable
expectation that others will see what was intended.
> For running ls, -w is the right option to use - but IN
> COMBINATION with correct settings for the terminal
> emulation AND the presence of a font that will do.
Yes. I'm still a little embarrassed for having completely overlooked
that option earlier. Hasty (impatient) reading of man p
Re: "Unprintable" 8-bit characters
--As of November 8, 2011 7:58:04 PM -0600, Conrad J. Sabatier is alleged to have said: So, what would be the safest bet as far as the most "universal" representation for these characters? Something I've long wondered about when I've e-mailed people and copied/pasted these characters (are they really seeing what I'm seeing?). :-) --As for the rest, it is mine. These days, the safest bet is UTF-8, or some other Unicode character set, in something that can convey what character set it is in. (Email can, depending on the mail client.) Not that Unicode is universal yet, but it designed to be (and is, generally) a solution to the 'multiple character encodings' problem. (By, of course, defining a new encoding.) It has a decent amount of traction, and in a decade or so - once other options have been firmly depreciated - I'd expect we could start discussing whether to switch ls to using it by default. ;) All this is of course if you *must* go beyond 7-bit ASCII. (Which all forms of Unicode is designed to be a strict superset of.) Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Wed, 09 Nov 2011 02:51:31 +0100
"Michael Ross" wrote:
> Am 09.11.2011, 01:42 Uhr, schrieb Conrad J. Sabatier
> :
>
> > Pardon me if this may seem like a stupid question, but this is
> > something that's been bugging me for a long time, and none of my
> > research has turned up anything useful yet.
> >
> > I've been trying to understand what the deal is with regards to the
> > displaying of the "extended" 8-bit character set, i.e., 8-bit
> > characters with the MSB set.
> >
> > More specifically, I'm trying to figure out how to get the "ls"
> > command to properly display filenames containing characters in this
> > extended set. I have some MP3 files, for instance, whose names
> > contain certain European characters, such as the lowercase "u" with
> > umlaut (code 0xfc in the Latin set, according to gucharmap), that I
> > just can't get ls to display properly. These characters seem to be
> > considered by ls as "unprintable", and the best I've been able to
> > produce in the ls output is backslash interpretations of the
> > characters using either the -B or -b options, otherwise the default
> > "?" is displayed in their place.
>
> Unsure if I understand you correctly.
> ("extended" 8-bit character set with MSB? utf-16?)
> I'm confused by this charset stuff in general.
That is to say, "8-bit characters with the most significant bit set",
or "characters greater than 0x7f".
I can certainly appreciate your confusion; this is definitely a
confusing area. In gucharmap, selecting the unlauted "u" in the Latin
set, the "Character Details" tab reveals the following:
U+00FC LATIN SMALL LETTER U WITH DIAERESIS
General Character Properties
In Unicode since: 1.1
Unicode category: Letter, Lowercase
Canonical decomposition: U+0075 LATIN SMALL LETTER U + U+0308 COMBINING
DIAERESIS
Various Useful Representations
UTF-8: 0xC3 0xBC
UTF-16: 0x00FC
C octal escaped UTF-8: \303\274
XML decimal entity: ü
So apparently, it's a "wide" character in UTF-8, which really throws a
monkey wrench into the works in certain situations (for example, one of
the little scripts I've written to process MP3 files uses the "cut"
command, which complains about an "illegal byte sequence").
Even more confusing, selecting the character and copying it to the
clipboard, the UTF-16 representation (0xfc) is what actually gets
used. Pasting this single-byte version into an X terminal (any of
them: xterm, gnome-terminal, etc.) does display the correct character,
an umlauted "u", even if using an 8-bit locale, such as UTF-8. Majorly
confusing!
> Assuming you want \0xfc displayed as "ü",
Yes, exactly.
> > cat test.py && python test.py && ls -l
>
> #!/usr/local/bin/python
> # -*- coding: utf-8 -*-
>
> f=open('\xfc','w')
> f.close()
> total 2
>
> -rw-r--r-- 1 michael wheel 29 9 Nov 02:43 test.py
> -rw-r--r-- 1 michael wheel 0 9 Nov 02:44 ü
>
>
> here is what works for me:
>
> in my login class in /etc/login.conf:
>
> :charset=ISO-8859-1:\
> :lang=de_DE.ISO8859-1:\
>
> ``cap_mkdb /etc/login.conf'' after changes
>
>
> in /etc/rc.conf:
>
> scrnmap="iso-8859-1_to_cp437"
> font8x8="cp850-8x8"
> font8x14="cp850-8x14"
> font8x16="cp850-8x16"
>
>
> and in /etc/ttys, console type is set to ``cons25l1''
Thanks, I hadn't considered making those sorts of changes for the
console. I work so seldom nowadays in the console, I'd forgotten all
about that stuff (use it or lose it, as they say!). I'll certainly give
that a try.
Much appreciation for both yours and Robert's replies.
--
Conrad J. Sabatier
conr...@cox.net
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Tue, 8 Nov 2011 19:58:04 -0600, Conrad J. Sabatier wrote:
> So, what would be the safest bet as far as the most "universal"
> representation for these characters? Something I've long wondered
> about when I've e-mailed people and copied/pasted these characters (are
> they really seeing what I'm seeing?). :-)
With lots of experience in "how not to do it", I would
like to suggest the following: Use US-ASCII letters only.
This makes _sure_ they will display correctly everywhere
and even on ultra-worst conditions (e. g. you are at a
real serial console, a real DEC vt100).
Filenames like kloesze_mit_muesli_foerdern_baerenhunger.mp3
can be processed by _any_ ls or mailer program. There is
no need to worry about... hmmm... do they have the same
character settings that I use? Do they have a font installed
that can show the file names properly?
Rules: Substitute umlauts properly (*e). Substitute ß
to sz ("teletype convention"). Remove accents or other
marks completely, as well as "strokes through characters"
or similar typographical specialities. If you can, use
lowercase only. No spaces, use _ instead. Avoid any other
special characters. Make everything plain ASCII, and you
can _still_ easily get the meaning.
The file system ITSELF doesn't care for the meaning of
the characters. SAVING them and DISPLAYING them are two
fully different things. Nobody stops you from making
filenames like öÜÖß߀Łµ³¼`łøæſđ̣ĸ»¢.mp3, but they can
cause trouble you can't predict. You _never_ know...
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Wed, 09 Nov 2011 02:51:31 +0100, Michael Ross wrote:
> Am 09.11.2011, 01:42 Uhr, schrieb Conrad J. Sabatier :
>
> > Pardon me if this may seem like a stupid question, but this is
> > something that's been bugging me for a long time, and none of my
> > research has turned up anything useful yet.
> >
> > I've been trying to understand what the deal is with regards to the
> > displaying of the "extended" 8-bit character set, i.e., 8-bit characters
> > with the MSB set.
> >
> > More specifically, I'm trying to figure out how to get the "ls" command
> > to properly display filenames containing characters in this extended
> > set. I have some MP3 files, for instance, whose names contain certain
> > European characters, such as the lowercase "u" with umlaut (code 0xfc
> > in the Latin set, according to gucharmap), that I just can't get ls to
> > display properly. These characters seem to be considered by ls as
> > "unprintable", and the best I've been able to produce in the ls
> > output is backslash interpretations of the characters using either the
> > -B or -b options, otherwise the default "?" is displayed in their place.
>
> Unsure if I understand you correctly.
> ("extended" 8-bit character set with MSB? utf-16?)
> I'm confused by this charset stuff in general.
>
> Assuming you want \0xfc displayed as "ü",
>
> > cat test.py && python test.py && ls -l
>
> #!/usr/local/bin/python
> # -*- coding: utf-8 -*-
>
> f=open('\xfc','w')
> f.close()
> total 2
>
> -rw-r--r-- 1 michael wheel 29 9 Nov 02:43 test.py
> -rw-r--r-- 1 michael wheel 0 9 Nov 02:44 ü
>
>
> here is what works for me:
>
> in my login class in /etc/login.conf:
>
> :charset=ISO-8859-1:\
> :lang=de_DE.ISO8859-1:\
>
> ``cap_mkdb /etc/login.conf'' after changes
Ah, thanks - that seems to be the proper way to have
the environmental variables set - instead of my (ab)use
of setenv's in the csh config file. :-)
Note the "precedence" of $LANG vs. $LC_* (as they can
be used to configure things more precisely, e. g.
regarding system messages or date formats; see example
following).
> in /etc/rc.conf:
>
> scrnmap="iso-8859-1_to_cp437"
Hm? CP437? Codepage? Isn't that some MS-DOS thing?
I've never needed a screenmap to make "extended
characters" (everything beyong US-ASCII) work.
> font8x8="cp850-8x8"
> font8x14="cp850-8x14"
> font8x16="cp850-8x16"
>
>
> and in /etc/ttys, console type is set to ``cons25l1''
I have a similar setting here, but that does _not_ work
wuth UTF-8 codec characters. If I want to use them, I
have to change some environmental variables, from
#---GERMAN/ENGLISH <=== DEFAULT
setenv LC_ALL en_US.ISO8859-1
setenv LC_MESSAGES en_US.ISO8859-1
setenv LC_COLLATE de_DE.ISO8859-1
setenv LC_CTYPEde_DE.ISO8859-1
setenv LC_MONETARY de_DE.ISO8859-1
setenv LC_NUMERIC de_DE.ISO8859-1
setenv LC_TIME de_DE.ISO8859-1
unsetenv LANG
to
#---INTERNATIONAL-
setenv LC_ALL en_US.UTF-8
setenv LC_MESSAGES en_US.UTF-8
setenv LC_COLLATE de_DE.UTF-8
setenv LC_CTYPEde_DE.UTF-8
setenv LC_MONETARY de_DE.UTF-8
setenv LC_NUMERIC de_DE.UTF-8
setenv LC_TIME de_DE.UTF-8
setenv LANGde_DE.UTF-8
Then I can use UTF-8 characters inside rxvt-unicode. Of
course, text mode console is limited to the first set
of configuration, using the ISO 8859-1 character set.
This worked long before UTF-8 arrived with the glorious
idea that I should have 2 bytes where one is sufficient,
to describe our (german) 6 umlauts and the Eszett ligature. :-)
Improper settings will result in [][] or A-tilde three
quarters upside-down question mark, depending on editor
or terminal used.
But returning to the original question, I think Robert
did explain it very well: There is no real consensus
about what the different codings should mean. They
were meant to unify the representation of a very large
set of characters, but basically there are many inter-
pretations now, and how they show up to the user depends
on the font in use, _if_ it has this mapping or that,
or none.
For running ls, -w is the right option to use - but IN
COMBINATION with correct settings for the terminal
emulation AND the presence of a font that will do.
Again a fine demonstration why file names should be
limited to printable ASCII and no spaces if you want
them to work everywhere. :-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Tue, 8 Nov 2011 19:17:27 -0600 (CST) Robert Bonomi wrote: > > On Tue, 8 Nov 2011 18:42:36 -0600, "Conrad J. Sabatier" wrote: > > > > I've been trying to understand what the deal is with regards to the > > displaying of the "extended" 8-bit character set, i.e., 8-bit > > characters with the MSB set. > > Quite simply Unix dates from the days where the 8th bit was used as a > 'parity' bit. Allowing detection of *all* single-bit errors -- > especially over the notoriously un-reliable connections known as > 'serial ports'. > > > > More specifically, I'm trying to figure out how to get the "ls" > > command to properly display filenames containing characters in this > > extended set. I have some MP3 files, for instance, whose names > > contain certain European characters, such as the lowercase "u" with > > umlaut (code 0xfc in the Latin set, according to gucharmap), that I > > just can't get ls to display properly. These characters seem to be > > considered by ls as "unprintable", and the best I've been able to > > produce in the ls output is backslash interpretations of the > > characters using either the -B or -b options, otherwise the default > > "?" is displayed in their place. > > > > The strange thing is that these characters will display just fine in > > xterm, gnome-terminal, etc. I can copy and paste them from the > > gucharmap utility into a shell command line or other application, > > and they appear as they should, but ls simply refuses to display > > them. I can print them using the printf command, even bash's > > builtin echo seems to have no problem with them. Only ls appears > > to have this problem. > > > > I've experimented with using various locales, using the LC_* > > variables, as well as the LANG variable (as documented in the > > environment section of the ls man page), all to no avail. > > Obviously you never read as far as the '-w' switch. Just a quickie followup: Setting LC_ALL=en_US.UTF-8 and using "ls -w" was, in fact, the magic key (at least, in any of the X terminal apps; still getting the little "exponential n" in the console)! Thank you so much. I'll sleep much better tonight. :-) -- Conrad J. Sabatier conr...@cox.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Tue, 8 Nov 2011 19:17:27 -0600 (CST) Robert Bonomi wrote: > > On Tue, 8 Nov 2011 18:42:36 -0600, "Conrad J. Sabatier" wrote: > > > > I've been trying to understand what the deal is with regards to the > > displaying of the "extended" 8-bit character set, i.e., 8-bit > > characters with the MSB set. > > Quite simply Unix dates from the days where the 8th bit was used as a > 'parity' bit. Allowing detection of *all* single-bit errors -- > especially over the notoriously un-reliable connections known as > 'serial ports'. Ah, yes! The "good old days". :-) > > More specifically, I'm trying to figure out how to get the "ls" > > command to properly display filenames containing characters in this > > extended set. I have some MP3 files, for instance, whose names > > contain certain European characters, such as the lowercase "u" with > > umlaut (code 0xfc in the Latin set, according to gucharmap), that I > > just can't get ls to display properly. These characters seem to be > > considered by ls as "unprintable", and the best I've been able to > > produce in the ls output is backslash interpretations of the > > characters using either the -B or -b options, otherwise the default > > "?" is displayed in their place. > > > > The strange thing is that these characters will display just fine in > > xterm, gnome-terminal, etc. I can copy and paste them from the > > gucharmap utility into a shell command line or other application, > > and they appear as they should, but ls simply refuses to display > > them. I can print them using the printf command, even bash's > > builtin echo seems to have no problem with them. Only ls appears > > to have this problem. > > > > I've experimented with using various locales, using the LC_* > > variables, as well as the LANG variable (as documented in the > > environment section of the ls man page), all to no avail. > > Obviously you never read as far as the '-w' switch. Yes, somehow that one went right past me. Haste makes waste! :-) > > Is this an inherent limitation of ls, > > It is -not- a limitation; rather it is a _desired_ behavior -- so > that one can _tell_ where there is an 'unprintable' character (like > \r, or\b) in a filename. There are *good*reasons*(TM) why -q is the > default behavior for 'terminal' output. OK, I can see that. :-) > > or is there some workaround or > > other solution? Do we need a new en_*.UTF-16 locale? Should we > > consider extending the ls command to handle these characters? > > There _are_ "improved" versions of ls that do understand the 'locale' > environment variables -- but those programs introduce a whole bunch of > *other* 'not necessarily desired' behaviors -- like sorting > upper-case and lower-case letters as 'equals', rather than regarding > any upper-case as sorting before any lowercase. Well, *that* certainly won't do! That should be the exception, not the rule. > > Or is > > there just something about all of this that I'm just not "getting"? > > > > As an additional note, I notice that in the text console, this same > > character code (0xfc) produces an entirely different character (a > > lowercase n in a raised position, as for the exponent in a > > mathematical expression). Is there, in fact, no standardization > > re: the representation of these "high bit" characters? > > "The nice thing about standards is that there are so many to choose > from" applies. WITH A VENGANCE!! > > There are at least FIFTEEN different sets of glyphs for the 'high bit > set' byte codes *JUST* for the 'iso-8859' base charset. Plus > 'utf-8' And not counting the various bastardiztions (e.g. 'CP-1252', > etc.) that Microsoft has introduced. > > > Thanks to anyone who can help clear up this long-standing mystery > > for me. > > eading he ine anpage -- with particular attention to the > '-q' and '-w' options should provie some enlightenment. Thank you very much. Some of this matched the suspicions I already had re: this matter. Don't know how I completely missed the -w switch. Mea culpa. :-) So, what would be the safest bet as far as the most "universal" representation for these characters? Something I've long wondered about when I've e-mailed people and copied/pasted these characters (are they really seeing what I'm seeing?). :-) -- Conrad J. Sabatier conr...@cox.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
Am 09.11.2011, 01:42 Uhr, schrieb Conrad J. Sabatier :
Pardon me if this may seem like a stupid question, but this is
something that's been bugging me for a long time, and none of my
research has turned up anything useful yet.
I've been trying to understand what the deal is with regards to the
displaying of the "extended" 8-bit character set, i.e., 8-bit characters
with the MSB set.
More specifically, I'm trying to figure out how to get the "ls" command
to properly display filenames containing characters in this extended
set. I have some MP3 files, for instance, whose names contain certain
European characters, such as the lowercase "u" with umlaut (code 0xfc
in the Latin set, according to gucharmap), that I just can't get ls to
display properly. These characters seem to be considered by ls as
"unprintable", and the best I've been able to produce in the ls
output is backslash interpretations of the characters using either the
-B or -b options, otherwise the default "?" is displayed in their place.
Unsure if I understand you correctly.
("extended" 8-bit character set with MSB? utf-16?)
I'm confused by this charset stuff in general.
Assuming you want \0xfc displayed as "ü",
cat test.py && python test.py && ls -l
#!/usr/local/bin/python
# -*- coding: utf-8 -*-
f=open('\xfc','w')
f.close()
total 2
-rw-r--r-- 1 michael wheel 29 9 Nov 02:43 test.py
-rw-r--r-- 1 michael wheel 0 9 Nov 02:44 ü
here is what works for me:
in my login class in /etc/login.conf:
:charset=ISO-8859-1:\
:lang=de_DE.ISO8859-1:\
``cap_mkdb /etc/login.conf'' after changes
in /etc/rc.conf:
scrnmap="iso-8859-1_to_cp437"
font8x8="cp850-8x8"
font8x14="cp850-8x14"
font8x16="cp850-8x16"
and in /etc/ttys, console type is set to ``cons25l1''
Regards,
Michael
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Polytropon wrote: On Tue, 8 Nov 2011 13:33:55 -0700 (MST), Warren Block wrote: On Tue, 8 Nov 2011, Warren Block wrote: On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option "DontZap" "off"'' in the "ServerFlags" section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. Nope, just tested and I'm wrong. DontZap Off is needed with X.Org X Server 1.7.7. Sorry about that. I recommend adding the option to ServerLayout and doing away with the extra complication of a ServerFlags section. Good suggestion, the Handbook should be changed according to that if it really works (and is, in my opinion, easier). It's already in there, right before Option "DontZap" "Off". ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: "Unprintable" 8-bit characters
On Tue, 8 Nov 2011 18:42:36 -0600, "Conrad J. Sabatier" wrote: > > I've been trying to understand what the deal is with regards to the > displaying of the "extended" 8-bit character set, i.e., 8-bit characters > with the MSB set. Quite simply Unix dates from the days where the 8th bit was used as a 'parity' bit. Allowing detection of *all* single-bit errors -- especially over the notoriously un-reliable connections known as 'serial ports'. > > More specifically, I'm trying to figure out how to get the "ls" command > to properly display filenames containing characters in this extended > set. I have some MP3 files, for instance, whose names contain certain > European characters, such as the lowercase "u" with umlaut (code 0xfc > in the Latin set, according to gucharmap), that I just can't get ls to > display properly. These characters seem to be considered by ls as > "unprintable", and the best I've been able to produce in the ls > output is backslash interpretations of the characters using either the > -B or -b options, otherwise the default "?" is displayed in their place. > > The strange thing is that these characters will display just fine in > xterm, gnome-terminal, etc. I can copy and paste them from the > gucharmap utility into a shell command line or other application, and > they appear as they should, but ls simply refuses to display them. I > can print them using the printf command, even bash's builtin echo seems > to have no problem with them. Only ls appears to have this problem. > > I've experimented with using various locales, using the LC_* > variables, as well as the LANG variable (as documented in the > environment section of the ls man page), all to no avail. Obviously you never read as far as the '-w' switch. > Is this an inherent limitation of ls, It is -not- a limitation; rather it is a _desired_ behavior -- so that one can _tell_ where there is an 'unprintable' character (like \r, or\b) in a filename. There are *good*reasons*(TM) why -q is the default behavior for 'terminal' output. > or is there some workaround or > other solution? Do we need a new en_*.UTF-16 locale? Should we > consider extending the ls command to handle these characters? There _are_ "improved" versions of ls that do understand the 'locale' environment variables -- but those programs introduce a whole bunch of *other* 'not necessarily desired' behaviors -- like sorting upper-case and lower-case letters as 'equals', rather than regarding any upper-case as sorting before any lowercase. >Or is > there just something about all of this that I'm just not "getting"? > > As an additional note, I notice that in the text console, this same > character code (0xfc) produces an entirely different character (a > lowercase n in a raised position, as for the exponent in a mathematical > expression). Is there, in fact, no standardization re: the > representation of these "high bit" characters? "The nice thing about standards is that there are so many to choose from" applies. WITH A VENGANCE!! There are at least FIFTEEN different sets of glyphs for the 'high bit set' byte codes *JUST* for the 'iso-8859' base charset. Plus 'utf-8' And not counting the various bastardiztions (e.g. 'CP-1252', etc.) that Microsoft has introduced. > Thanks to anyone who can help clear up this long-standing mystery for > me. eading he ine anpage -- with particular attention to the '-q' and '-w' options should provie some enlightenment. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: operapluginwraper
On Tue, 8 Nov 2011, ajtiM wrote: On my FreeBSD 8.2 Release I use KDE 4 and Opera 11.52. Everytime when I start (use) Opera I have operapluginwraper..core in the /home directory.. In the /var/log/mesages I got also: Nov 8 15:15:20 athena console-kit-daemon[1395]: WARNING: kvm_getenvv failed: cannot open /proc/4679/mem [snip] I don't have /proc on my system and I don't know why I should have it? This might have to do with the linuxulator. At some point I added linproc /usr/compat/linux/proc linprocfs rw00 ...to my /etc/fstab. I have a note in that file saying that it came from http://www.freebsd.org/doc/en/books/handbook/desktop-browsers.html I don't recall if I had to create that directory; I suspect it appeared automagically. I see: $ ls -l /usr/compat/linux | grep proc dr-xr-xr-x 1 root wheel 0 Nov 8 19:15 proc ...which was just a moment ago. HTH. -- Chris Hill ch...@monochrome.org ** [ Busy Expunging ] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: operapluginwraper
On Tue, 8 Nov 2011 15:33:01 -0600, ajtiM wrote: > I don't have /proc on my system and I don't know why I should have it? You'll need it in case you're using Linux ABI stuff, and if I remember correctly, this is required for the Opera "Flash" plugin. I'm using such a combination here. That's why I have # Device Mountpoint FStype Options Dump Pass # - -- --- --- - linproc /compat/linux/proc linprocfsrw 00 in /etc/fstab. This requires options COMPAT_LINUX options LINPROCFS options LINSYSFS in your kernel config, or load the corresponding kernel modules. The line linux_enable="YES" in /etc/rc.conf should do that. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
"Unprintable" 8-bit characters
Pardon me if this may seem like a stupid question, but this is something that's been bugging me for a long time, and none of my research has turned up anything useful yet. I've been trying to understand what the deal is with regards to the displaying of the "extended" 8-bit character set, i.e., 8-bit characters with the MSB set. More specifically, I'm trying to figure out how to get the "ls" command to properly display filenames containing characters in this extended set. I have some MP3 files, for instance, whose names contain certain European characters, such as the lowercase "u" with umlaut (code 0xfc in the Latin set, according to gucharmap), that I just can't get ls to display properly. These characters seem to be considered by ls as "unprintable", and the best I've been able to produce in the ls output is backslash interpretations of the characters using either the -B or -b options, otherwise the default "?" is displayed in their place. The strange thing is that these characters will display just fine in xterm, gnome-terminal, etc. I can copy and paste them from the gucharmap utility into a shell command line or other application, and they appear as they should, but ls simply refuses to display them. I can print them using the printf command, even bash's builtin echo seems to have no problem with them. Only ls appears to have this problem. I've experimented with using various locales, using the LC_* variables, as well as the LANG variable (as documented in the environment section of the ls man page), all to no avail. Is this an inherent limitation of ls, or is there some workaround or other solution? Do we need a new en_*.UTF-16 locale? Should we consider extending the ls command to handle these characters? Or is there just something about all of this that I'm just not "getting"? As an additional note, I notice that in the text console, this same character code (0xfc) produces an entirely different character (a lowercase n in a raised position, as for the exponent in a mathematical expression). Is there, in fact, no standardization re: the representation of these "high bit" characters? Thanks to anyone who can help clear up this long-standing mystery for me. -- Conrad J. Sabatier conr...@cox.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
operapluginwraper
Hi! On my FreeBSD 8.2 Release I use KDE 4 and Opera 11.52. Everytime when I start (use) Opera I have operapluginwraper..core in the /home directory.. In the /var/log/mesages I got also: Nov 8 15:15:20 athena console-kit-daemon[1395]: WARNING: kvm_getenvv failed: cannot open /proc/4679/mem Nov 8 15:15:43 athena hp-systray: hp-systray[4753]: error: option -s not recognized Nov 8 15:15:50 athena dbus[1131]: [system] Failed to activate service 'org.freedesktop.Avahi': timed out Nov 8 15:16:00 athena console-kit-daemon[1395]: WARNING: kvm_getenvv failed: cannot open /proc/4766/mem Nov 8 15:20:56 athena console-kit-daemon[1395]: WARNING: kvm_getenvv failed: cannot open /proc/4689/mem Nov 8 15:20:56 athena console-kit-daemon[1395]: WARNING: kvm_getenvv failed: cannot open /proc/4689/mem Nov 8 15:24:58 athena su: ajtim to root on /dev/pts/1 Nov 8 15:25:43 athena kernel: pid 5937 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:25:43 athena kernel: pid 5941 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:25:43 athena kernel: pid 5943 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:25:43 athena kernel: pid 5945 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:25:43 athena kernel: pid 5947 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:27:43 athena kernel: pid 5965 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:27:43 athena kernel: pid 5969 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:27:43 athena kernel: pid 5971 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:27:43 athena kernel: pid 5973 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:27:43 athena kernel: pid 5975 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:28:30 athena kernel: pid 5982 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:28:30 athena kernel: pid 5986 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:28:30 athena kernel: pid 5988 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:28:30 athena kernel: pid 5990 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) Nov 8 15:28:30 athena kernel: pid 5992 (operapluginwrapper.), uid 1001: exited on signal 11 (core dumped) I don't have /proc on my system and I don't know why I should have it? Thanks in advance. Mitja http://jpgmag.com/people/lumiwa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011 13:33:55 -0700 (MST), Warren Block wrote: > On Tue, 8 Nov 2011, Warren Block wrote: > > > On Tue, 8 Nov 2011, Polytropon wrote: > > > >> And according to the handbook, this does _not_ remove the > >> need for a X configuration file (usually /etc/X11/xorg.conf) > >> including ``Option "DontZap" "off"'' in the "ServerFlags" > >> section. > > > > For at least the most recent Xorg, it's not needed. Can't recall whether > > it > > is for the one before that. > > Nope, just tested and I'm wrong. DontZap Off is needed with X.Org X > Server 1.7.7. Sorry about that. > > I recommend adding the option to ServerLayout and doing away with the > extra complication of a ServerFlags section. Good suggestion, the Handbook should be changed according to that if it really works (and is, in my opinion, easier). My statement regarding the xorg.conf _and_ XML fun wasn't a personal experience and testing (xorg-server-1.7.7_2,1 here), but the Handbook said so: http://www.freebsd.org/doc/handbook/x-config.html It's mentioned directly beneath the XML fun in 6.4.2. There's also a ServerLayout _or_ ServerFlags statement for the ``Option "AutoAddDevices" "false"'' setting, right before the XML fun for setting a localized keyboard begins... :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Warren Block wrote: On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option "DontZap" "off"'' in the "ServerFlags" section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. Nope, just tested and I'm wrong. DontZap Off is needed with X.Org X Server 1.7.7. Sorry about that. I recommend adding the option to ServerLayout and doing away with the extra complication of a ServerFlags section. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Polytropon wrote: And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option "DontZap" "off"'' in the "ServerFlags" section. For at least the most recent Xorg, it's not needed. Can't recall whether it is for the one before that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011 08:14:48 -0700 (MST), Warren Block wrote: > On Tue, 8 Nov 2011, Samuel Magnusson wrote: > > > 1. I can?t zap the server with Ctrl-Alt-Backspace. Nothing at all happens. > > I > > have checked that it isn't disabled in xorg.conf, and even tried to put in > > the reverse boolean value there. Not that I couldn't live without zapping, > > but...when I know about it that it should be there and it is taken fom me I > > feel an URGE to get the zap! > > Zapping is still allowed by default, but a key combination is not > assigned. That can be done in .xinitrc or .xsession: > >setxkbmap -option terminate:ctrl_alt_bksp > > It can also be done in xorg.conf: > >Section "InputDevice" > Identifier "Keyboard0" > Driver "kbd" > Option "XkbOptions" "terminate:ctrl_alt_bksp" >EndSection There is a 3rd option, especially "useful" when X is run with DBUS and HAL (the default configuration, as well as the package configuration), and it involves fun with XML. :-) File /usr/local/etc/hal/fdi/policy/x11-input.fdi terminate:ctrl_alt_bksp And according to the handbook, this does _not_ remove the need for a X configuration file (usually /etc/X11/xorg.conf) including ``Option "DontZap" "off"'' in the "ServerFlags" section. So, as you're already dealing with xorg.conf, use Warren's suggestion, as it works independently of all the "new" things required by X, and also conforms to the concept of concentrating X's configuration in one configuration file (rather than scattering settings across the file system). > vesa is very limited, only supporting standard modes up to 1024x768 or > 1280x1024. Some vendors add other modes, but they aren't common. > nouveau is an open driver for the very closed Nvidia hardware. The > closed Nvidia drivers (x11/nvidia-driver*) are supposed to work quite > well. I'm using nvidia-driver here which works better than nouveau and nv (the one that comes with X.org); I haven't tested VESA as in most cases, it's _not_ what one wants. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: zfs file names (inodes) without files (ENOENT)
On Mon, Nov 7, 2011 at 11:12 PM, Martin von Gagern wrote: > Thought the same, and gave it a try. zpool claims there is no pool of > that name. "zpool -f" doesn't help. Looking at the device nodes, it > appears as though OI would only recognize 3 of my 4 HDDs, which seems > really strange, given the fact that they're all wired the same way. That is pretty odd. OI's biggest weakness is hardware support, IMHO. The kernel is written by Sun (well, Oracle, now) and they have no interest in supporting hardware they don't sell. Drivers for commodity hardware are often buggy or nonexistent. It reminds me of the early, early days of Linux and BSD, where you'd have to buy and return three SCSI cards before you got one that worked. > OI boot process provides too little information for my taste Yeah, it's *quite* terse. The OI text console in general is lacking in refinement; Sun hardware grew frame buffers pretty early, so the assumption was you'd either be running some windowing environment (if you were physically at the system) or you'd be using a serial console (if it's a headless server.) Trying to administer an OI box via the system console tends to be an exercise in frustration. > So I'm heading towards Linux now, as no solution to the FreeBSD ZFS > problems seems to be forthcoming. Will probably be running some tandem > of btrfs and Ext4 for now, until btrfs becomes more mature or space > requirements force me to drop one of those file systems. I share your frustrations. I would really like to see btrfs mature. I really want a filesystem with pooled free space and transparent compression, but I've found OI frustrating from a hardware standpoint. I didn't have the problems you did with the FreeBSD ZFS implementation (maybe because I didn't dig into it very far), but I do need NFSv4, and the performance of FreeBSD's NFSv4 server is just too slow for me to consider it a reasonable replacement. So I'm kind of left with no way to get everything I want in one OS. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: OH NO! IT says my root partition / is full but it isn't! Why is FreeBSD lying about space?
We FOUND IT. We did do the procedure that Michael recommended, but unfortunately none of the nfs mount labels /var /usr /tmp contained any data after booting into single user mode. What we did find was a NFS folder that contained a huge 300 meg .tar.gz file that wasn't finished downloading. (Was a BSDSRC tree that was tar'd gz'd) Have to watch for massive NFS file transfers of abnormally large files -- that is what caused the issue. Next time we'll use WGET instead while sitting at the /usr partition instead of the root folder. From: Lowell Gilbert To: rtsit Cc: "freebsd-questions@freebsd.org" Sent: Monday, November 7, 2011 1:13 PM Subject: Re: OH NO! IT says my root partition / is full but it isn't! Why is FreeBSD lying about space? rtsit writes: > I did reboot the machine a few times, hoping that any process in > memory that still claimed ownership of an open part of the disk would > release it. There are other things that can cause disk space to seem to disappear, but there is a reason that one is in the FAQ list and the others aren't; it's virtually always the cause when someone reports such a problem on this list. > Didn't work. I'm going to try the other method recommended by Michael > Sierchio -- to reboot in single user mode and try and clear out any > directory structures that could exist that my mount labels could be > hiding. Thanks for the reply and helpful link. If the mounts are shadowing files, that will certainly hide data use. I hope that turns out to be the issue and you get it fixed quickly. > (It was nice to not see a RTFM response, but a helpful link -- it is > appreciated). I don't agree with you here. My response *was* RTFM, and I don't see anything inherently wrong with that. I'm glad it was helpful. Good luck. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: recursive copy with spaces in descendants
On 05/11/2011 19:47, Chris wrote: I'm having difficulty copying a directory tree from my FreeBSD server to USB storage. The problem is that the tree contains file and folder names which have spaces, similar to the following: ./foo bar/some name.tar.gz ./foo bar/child dir/some other name.tar.gz I've tried various combinations of cp with enclosing the top level directory in quotations, along with other commands like tar or xargs to no avail. The problem seems to be with creating the destination directories and folders, where mkdir/cp terminates with an invalid argument response. Cleaning up the source filenames using something like detox isn't viable, as the files are being served by transmission-daemon, and as such the names must be preserved. Permissions are not an issue either, as the same responses occur whether I use a standard or root account. Any ideas would be greatly appreciated, since I'm pretty much out of them at this point. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" %mount_msdosfs /dev/da0s1 mnt #USB external HD %ls mnt %cd ~/temp2 %find . . ./dir with spaces ./dir with spaces/file1 with spaces ./dir with spaces/file2 with spaces %find . -depth |cpio -pdmv ~/mnt /home/chrisw/mnt/./dir with spaces/file1 with spaces /home/chrisw/mnt/./dir with spaces/file2 with spaces /home/chrisw/mnt/./dir with spaces /home/chrisw/mnt/. 0 blocks %find ~/mnt /home/chrisw/mnt /home/chrisw/mnt/dir with spaces /home/chrisw/mnt/dir with spaces/file1 with spaces /home/chrisw/mnt/dir with spaces/file2 with spaces or have I missed something? Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: X server and xinit works excellent....almost.
On Tue, 8 Nov 2011, Samuel Magnusson wrote: 1. I can?t zap the server with Ctrl-Alt-Backspace. Nothing at all happens. I have checked that it isn't disabled in xorg.conf, and even tried to put in the reverse boolean value there. Not that I couldn't live without zapping, but...when I know about it that it should be there and it is taken fom me I feel an URGE to get the zap! Zapping is still allowed by default, but a key combination is not assigned. That can be done in .xinitrc or .xsession: setxkbmap -option terminate:ctrl_alt_bksp It can also be done in xorg.conf: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbOptions" "terminate:ctrl_alt_bksp" EndSection 2. Not surprisingly I was also unable to use the Ctrl-Alt-Keypad+/- for zooming between the different resolution modes. But then I remembered that I had changed configuration from vesa driver to nouveau (with some patch that I downloaded according to instructions in ports). When I switched back to vesa it worked! Still no zapping though, and no higher resolution than 1024x768. vesa is very limited, only supporting standard modes up to 1024x768 or 1280x1024. Some vendors add other modes, but they aren't common. nouveau is an open driver for the very closed Nvidia hardware. The closed Nvidia drivers (x11/nvidia-driver*) are supposed to work quite well. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: /sys/amd64/conf/DEFAULTS
Am 11/08/11 14:12, schrieb Niclas Zeising: > On 11/08/11 12:36, O. Hartmann wrote: >> Sorry for the boring question, but is the default configuration file >> /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration >> file for the kernel while building the kernel? >> >> I looked for include statements in GENERIC, but didn't find one. I use >> custom kernel config files and adapt most changes from the NOTES files >> in the sources tree. >> >> With the today's update of README in /sys/amd64/conf I realised some >> important changes, so this triggered my question. >> >> I simply made an additional "include" in the custom config file, but if >> this isn't necessary, I'll delete it again. And I'm interested in how >> the kernel is built from. It is a very convenient way to type simply >> "make kerne" in /usr/src/, but it vanishes to much of the complexity and >> understanding how the system builds and could cause problems. >> >> Thanks for your patience and tahnks in advance, >> >> Regards, >> Oliver > > From my understanding of things, the DEFAULTS kernel configuration file > is automatically included into the build by config(8). There is no need > to include it into the generic using the "include" statement. It was > first added 6 years ago, on October 27 2005. > Regards! Thank you very much. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: /sys/amd64/conf/DEFAULTS
On 11/08/11 12:36, O. Hartmann wrote: Sorry for the boring question, but is the default configuration file /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration file for the kernel while building the kernel? I looked for include statements in GENERIC, but didn't find one. I use custom kernel config files and adapt most changes from the NOTES files in the sources tree. With the today's update of README in /sys/amd64/conf I realised some important changes, so this triggered my question. I simply made an additional "include" in the custom config file, but if this isn't necessary, I'll delete it again. And I'm interested in how the kernel is built from. It is a very convenient way to type simply "make kerne" in /usr/src/, but it vanishes to much of the complexity and understanding how the system builds and could cause problems. Thanks for your patience and tahnks in advance, Regards, Oliver From my understanding of things, the DEFAULTS kernel configuration file is automatically included into the build by config(8). There is no need to include it into the generic using the "include" statement. It was first added 6 years ago, on October 27 2005. Regards! -- Niclas Zeising ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: FreeBSD idea
On Tue, 08 Nov 2011 11:20:12 +1100 David Morton wrote: > I'm very new to BSD, and had a career that left me mostly doing > commercial IT help desk in Windows, but am hoping to finally learn > and do something of interest to me: get deep knowledge of one > platform. > > A local magazine, Silicon Chip; and one of it's writers have > developed a little computer called the MaxiMite. Details here: > http://geoffg.net/maximite.html It's a PIC32 single chip computer > that I use through USB emulation of a serial port. Since you are new to BSD you might not be aware that the three main versions of BSD, have different priorities. OpenBSD focuses on security, NetBSD focuses on portability and FreeBSD aims to be an all-round OS with more emphasis on performance on mainstream hardware. IIWY I'd be looking at NetBSD. I suspect that this computer (and PIC32 in general) doesn't have a proper memory management unit, and that that will make it difficult to port most modern general-purpose OSes. I'd check to see if NetBSD has been run on a PIC32 (rather than MIPS in general). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: console-kit daemon
On Monday 07 November 2011 18:34:16 Chuck Swiger wrote: > On Nov 7, 2011, at 4:19 PM, ajtiM wrote: > > I ahve a problem that computer freeze when I compailing ports without > > error. Sometimes freeze (hard reset help) and sometimes reboot. > > I did ran memtest 24 hours and there were no errors, I used smartmontools > > for check hard drive and there are no errors but the problem is here > > still. > > Running memtest is a great diagnostic for bad memory. > > It's good that it passed; so this suggests thermal problems, or less > likely, a marginal power supply unit which can't handle full load. > prime95 / mprime has a diagnostic mode which lets you fully load up both > CPU and memory resources, and might be better suited to identifying a > problem if memtest didn't find anything > > Regards, Thank you very much. I will try because I cannot do any update...but I am not ready yet to buy a new computer. Mitja http://jpgmag.com/people/lumiwa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
/sys/amd64/conf/DEFAULTS
Sorry for the boring question, but is the default configuration file /sys/amd64/conf/DEFAULTS anywhere include in a regular configuration file for the kernel while building the kernel? I looked for include statements in GENERIC, but didn't find one. I use custom kernel config files and adapt most changes from the NOTES files in the sources tree. With the today's update of README in /sys/amd64/conf I realised some important changes, so this triggered my question. I simply made an additional "include" in the custom config file, but if this isn't necessary, I'll delete it again. And I'm interested in how the kernel is built from. It is a very convenient way to type simply "make kerne" in /usr/src/, but it vanishes to much of the complexity and understanding how the system builds and could cause problems. Thanks for your patience and tahnks in advance, Regards, Oliver signature.asc Description: OpenPGP digital signature
