Tiny Core and games

[byteshaman]

i am installing geany. i see there is also a geany-locale.tcz, but i'm just gonna go for just geany.tcz

my first install attempt loaded a bunch of extensions, but then eventually failed.
i do see that it suggests we have vte.tcz - so i installed that
and tried geany again - and it appears to have installed correctly

so, i opened jp.txt in geany and SUCCESS!! i do see the japanese characters.

then i opened yahoo.jp in bon echo and saw a bunch of ?? - this doesnt really matter much - as i cant even read japanese, i just want system compatibility for if/when i install some japanese games. i suppose it would help to be able to display japanese characters in the browser - but it doesnt appear mandatory at this time.

what i am doing now is downloading urxvt - which i believe is an alternative to terminal? no...it says this is a terminal emulator. well, i installed it anyway. and then i installed bash. both installs onboot mode

well, i dont see urxvt, or bash in my apps menu, or on my wbar

jp.txt is a file on my flash drive that i am using to test this. it is a simple utf8 text file that has some characters copied and pasted from a japanese web article. in windows 7 i visited a japanese webpage, selected, copied, and pasted some jp text and saved it to my flashdrive as jp.txt

i went into terminal and
~# bash
and nothing happened

~# bash /mnt/flashdrive/jp.txt
and it just gave me some garbled junk

~# urxvt
which did open the urxvt terminal but with this warning : the locale is not supported by xlib, working without locale support

when i did
~# geany /mnt/flashdrive/jp.txt
in the regular terminal it opened the file and displayed jp characters in geany, but terminal had a bunch of garbled errors

when i did
~# geany /mnt/flashdrive/jp.txt
in urxvt it opened the file and displayed jp characters in geany, but and it only had a few errors, written in english and no garbled gibberish included.

to proceed forth from here i feel i would be taking shots in the dark

i am assuming what i want to do is : set urxvt as my regular terminal - which is instructed in the "utf8 everywhere" page. i will do this tomorrow, as i have already put in a few hrs of effort today, but just on a different project (not Tinycore). i'm tired.

i suppose if i did have any questions, is just what is the difference between bash and terminal and urxvt?
should i have installed urxvt-locale instead? why dont the fonts show in the browser?
there is a possibility that my questions require answers more advanced than my level.
if so, please allow me some baby steps. 

[Misalf]

The Terminal Emulator is the text based Command Line Interface (CLI) that is used to communicate with the operatin system so you can tell it what to do (instead of using the mouse in Graphical User Interface).
In ancient days there was no mouse and GUI but the CLI is still very useful today so it is "Emulated" inside a Graphical Interface (X).
What you can do in CLI / Terminal Emulater (scripting) is, in tinycore, interpreted by busybox but you can also install bash which is more featureful and some scripts even require bash and wont run via busybox.
Which Terminal Emulator you choose to use doesnt make much difference. Some are faster, like aterm, and some have better support for non english charachters like urxvt, so that might be a good choice.

I don't know about how to display japanese characters correctly either in console nor in web browser, sorry.

[byteshaman]

today i am going to review the UTF8 everywhere page.
i have read more of the wiki, and still just questions.
i understand the command line interface, although i rarely used it in windows.
i think what is throwing me off is :
usually when i see/read people speak of linux terminal - they bring up the CLI and say : this is terminal
usually when i see/read people speak of bash or bash shell - they bring up the CLI and say : this is bash shell

i dont know if there's much a difference. i'm sure there is a difference. i'm sure i need more practice and research to get this definitive difference. but i guess it doesnt hurt to ask.

another wierd thing is that all of my linux references will give slightly different files/commands and reference linux distro compatibility, debian, ubuntu, red hat, and there's always a slight difference. it seems as if its a random shot when i type these commands into the TC terminal. sometimes i get a response, sometimes i dont.
this isn't something i'm addressing yet, but just typing out anyway, as i will explore this later.
i am assuming it is necessary to get "gnu compatibility" to get more standard commands to work?
my assumptions are based on this :
http://distro.ibiblio.org/tinycorelinux/faq.html#compatibility

and i am still gaining understanding the nature of a "kernel". still just cranking away at it.

[byteshaman]

it seems as if i do have japanese language display, it also seems to be showing in the urxvt cli.
i also created the symbolic link so that my terminal icon on wbar opens urxvt.

next it seems as if i would use the bash shell. i am going to read up a bit more on that.
then i want to mount partitions with the utf-8 charset.
i am starting to understand this : http://www.utf8everywhere.org/

as far as messing with the core. i'm hesitant to run that command. i believe i will backup my install before proceeding with that one.

thanx everybody! i believe i have reached my goal of displaying cjk (well "J" so far) - and thats pretty much all for now.

[Misalf]

I'm more of a Windows user too. I just recently switched to Linux and I feel your confusion.
I understand the different shells as follows..

If you know the Command Prompt in Windows, you might know there is cmd.exe and COMMAND.COM.
COMMAND.COM is the Command Interpreter that was also already used in MS-DOS.

It is resposable for executing commands, either typed in directly via keyboard or via script (i.e. batch files = .bat). Some commands are built-in, some are found via %PATH% variable.

cmd.exe does basically the same but offers more/improved features for scripts (.bat & .cmd) and for the later Windows versions.

While in Windows the Command Prompt window (terminal) and the Command Interpreter (shell) is the same thing (either COMMAND.COM or cmd.exe), in Linux it is not.
You can run commands in any Terminal, like aterm or urxvt, but they might get interpreted by Busybox or Bash (or sh or ash or whatever).

[byteshaman]

so...terminal an/or urxvt is kinda like the view, and the shell like busybox/bash are the controller?
terminal and/or urxvt is the interface (as in command line interface) - and busybox/bash are the execution handlers?

if i understand correctly.

thank you for your response.

[tinypoodle]

User interface versus command interpreter

[theYinYeti]

Hey byteshaman, I was a bit busy lately, but here I am again

1— More than one “lang=”: no. This will probably just apply the last one. As I said, the locale you choose is actually just your preference, and you can only have one. Several locales are available on your computer, though, and you can change your preference on a per-application basis, with a command-line like:

Code: [Select]

env LANG=en_US.utf8 geany
2— SomeApp-locale.tcz: When you see such a package, as you saw for Geany, this package is mandatory for this program to have its interface (menus, dialogs…) in languages other than the native language of this program (usually English). This package usually is of no consequence for the features of the program; for example, Geany is always able to show and edit Japanese texts, wether its menus are in Japanese, or in English (provided the system is configured properlyh UTF-8, fonts…).

3— Bon Echo… From what I see on the Internet, this seems to be a rather old and unmaintained experimental browser, probably to prepare what has become Firefox 4 and later. You may want to change your browser.

4— Terminal, console, and so on… I’ll try to explain, and write as few mistakes as possible

In the old days there was the console (that’s software), runing in a terminal (that’s hardware): the console received user input, gave it to the running program, and returned this program’s output. The console was usually connected to some powerful server.
Here’s a famous example of a terminal:
http://en.wikipedia.org/wiki/VT100

Instead of booting directly to a target program running in the console, the user was welcomed (in the console) by a command-line interface called “sh”, with the added benefit of:
— having the opportunity to set some environment variables and settings before launching any program,
— being able to launch several programs in a row, or chain them with pipes,
— remembering previous commands through history,
— and so on.

Then X11 arrived (that was more than 25 years ago), with its own handling of characters, and no access to the console, although a Console program for X11 was usually available to see the output from programs running in background on the system.
Terminal emulators were created to bring back the power of the shell to X11. sh was programmed to interact with a terminal (sending specific codes, and expecting specific results). That’s why terminal emulators were written: existing command-line programs (such as sh) continued to run as they did before, thinking they were running in a terminal but actually running in an emulated terminal.
Here’s a page that sheds some light on the complexity of shell/terminal(emulator) interaction:
http://www.ibb.net/~anne/keyboard.html

Now you have to know that several families of terminals existed, some monochrome (black and white, or black and green…), some with 16 colors, some with 256 colors, and slight differences in other areas. Each set of features needed its set of code sequences to trigger them. Thus terminal emulators are not created equal: for example, XTerm “provides DEC VT102 and Tektronix 4014 compatible terminals for programs that can't use the window system directly. This version implements ISO/ANSI colors using the "new" color model (i.e., background color erase). It also implements most of the control sequences for VT220, as well as selected features from other DEC terminals such as VT320, VT420 and VT520.”. Other terminal emulators may have slightly different features. Apart from that, some terminal emulators can only handle 8bit characters (ISO-8859-*, ASCII…), and some can also do UTF-8.

More over, shells evolved too. Features were added, forks were done, features converged too )most notably between ksh and bash)… There is sh, then csh, then bash and tcsh, and ksh too, and don’t forget zsh. And ash, and… so on. bash is the standard on Linux.
Each shell has its own language for history management, jobs management, commands combinations, and so on.

5— UTF-8 and Windows: Beware! Windows programs have a tendency to put a totally useless thing called “BOM” (byte-order-mark) at the start of UTF-8 files, which may appear strangely when shown in other operating systems.

6— ~# bash and nothing happened: Either you don’t have bash installed (but then it should say “command not found”), or it did work and you simply had bash running inside the parent shell, just like any other program Type “exit” to get back to the parent shell.

7— bash /mnt/flashdrive/jp.txt: Your text file is not a shell script. You cannot ask bash to interpret it.

8— Differences between distributions: indeed… Each distribution chooses what it thinks is the best of Unix and starts from there: BSD style, Init V5, and so on. Then each chooses its way of managing packages. RPM and DEB are the most popular formats, but alternatives exist (in Slackware, TinyCore, Arch…), or just plain compiling from sources. There are too many things that can differ to list. Each choice in a distribution stems from a goal in this distribution; for example, TinyCore wants to be small. Choice is good

I hope this helps. ’later!

[byteshaman]

YinYeti : thank you sooooooo much.
my understanding is much better and this will help my operations here forward.
it is on my resolutions list to buy you a beer. if i had money right now i'd be paying someone to teach me this, so i'm gonna have to write that down and remember it when i get money.
instead, i guess the best i can do is put forth effort until i get money to buy you a beer. the best effort i can put forth is to attempt some sort of tiny core artwork for the tiny core artwork thread.

thank you. much appreciation. your knowledge is very valuable.