WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [SOLVED] Wrong locale / charset for FAT flash drive, maybe Unicode problem…  (Read 6742 times)

Offline theYinYeti

  • Full Member
  • ***
  • Posts: 177
    • YetI web site
Re: Wrong locale / charset for FAT flash drive, maybe Unicode problem…
« Reply #15 on: June 19, 2013, 03:21:23 AM »
@tinypoodle: That’s an excellent idea! I’ll first check the solution. If it works (UTF-8), I’ll probably redo it this way.

Offline theYinYeti

  • Full Member
  • ***
  • Posts: 177
    • YetI web site
Re: Wrong locale / charset for FAT flash drive, maybe Unicode problem…
« Reply #16 on: June 19, 2013, 07:23:02 AM »
OK. Problem solved. I changed /usr/sbin/rebuildfstab inside core.gz, this way:
Code: [Select]
sudo sed -i '
/%-15s %-15s %-8s/ i\
grep -i "lang=[^ ]*utf8" /proc/cmdline >/dev/null && OPTIONS="${OPTIONS},iocharset=utf8"
' usr/sbin/rebuildfstab
Which means that I add the option “iocharset=utf8” when the “lang” kernel parameter has been set to UTF-8.

All is not perfect yet (problem with urxvt) but that’s another issue. The current topic is solved as far as I’m concerned :-)

Offline gerald_clark

  • TinyCore Moderator
  • Hero Member
  • *****
  • Posts: 4254
If you use 'grep -q' you do not need to redirect its output to /dev/null.

Offline theYinYeti

  • Full Member
  • ***
  • Posts: 177
    • YetI web site
Hi gerald_clark :-)
You’re right. That’s what I usually do, but I know that -q is a rather new option to grep, and I did not know how crippled grep would be at this early stage of boot (that’s busybox’ grep). For example: busybox’ find command is a pain to use…

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
but I know that -q is a rather new option to grep

How new? I couldn't remember it not existing...

Quote
I did not know how crippled grep would be at this early stage of boot (that's busybox' grep). For example: busybox' find command is a pain to use...

You make an arbitrary personal opinion about 'find' sound like a commonly accepted fact, without any reasoning at all. I have neither happened to see any bug reports nor any complaints about it, while I use 'find' since many years as well for interactive use (terminal) as for non-interactive use (shell scripting) to full satisfaction.
Your suspicion that 'grep' might be crippled is lacking any foundation.
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline theYinYeti

  • Full Member
  • ***
  • Posts: 177
    • YetI web site
OK, maybe I did not use the right word. Maybe “crippled” should be changed to “limited” or the like. That’s what you get when dealing with non-English people like me :-)
My problem with find (I did not investigate grep, as the workaround I used was rather evident) is that it is lacking the “-printf” option, which allows to choose what properties of the entries found to display. I use this option a lot, and I miss it. But then, TinyCore has the “findutils” extension for people like me.
Have a good day!

[edit: I should add that I tend to be cautious since I regularly work with Unix shell like old SunOS, which are a real pain to work with, except when GNU tools are installed.]
« Last Edit: June 21, 2013, 03:52:04 AM by theYinYeti »

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Hi gerald_clark :-)
You're right. That's what I usually do, but I know that -q is a rather new option to grep, and I did not know how crippled grep would be at this early stage of boot (that's busybox' grep).

I just happened to stumble over some older busybox laying around here:

Code: [Select]
BusyBox v0.60.5 (2003.02.15-11:25+0000) multi-call binary

Usage: grep [-ihHnqvs] PATTERN [FILEs...]

[.....]

-q      be quiet. Returns 0 if result was found, 1 otherwise
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)