Linux.com

Feature: Community

Ask Linux.com: IT, Japanese, and crafting bigger and better bash scripts

By Linux.com Staff on July 12, 2008 (2:00:00 PM)

Share    Print    Comments   

In this week's exciting chapter of Linux.com forum traffic, planning for an IT career with emphasis on Linux, how to go multilingual and multiprocessor, and unanswered questions for programmers and sound gurus.

Linux: Stepping stone to systems administration

User crisnoh posed the IT career question in the Miscellaneous Discussion forum. "I have a vague sort of notion that I'd like to do systems administration, and wouldn't it be great if those systems were running Linux? The options as I see them are pretty broad and overwhelming. I'm just trying to find some information on what skills tend to be in pretty high demand, what sort of degree/certifications/whatever I should be pursuing, pretty much anything."

Khabi -- who has worked as a sysadmin for several years -- responded with some solid advice, including the mix of subjects to study up on (such as managing Internet services, basic programming, and databases), his own experience on the value of certification, and a few tips on finding that first job. "Something else that will help more then you think: Completely switch over to a Linux distro on your home machine. Forcing yourself to use it day in and day out will help a *great* deal. Especially, if there aren't any ports for apps you need in Linux. Finding / troubleshooting / installing apps that could fill the functionality you're used to having will build your skillset."

Multiple processors and GNU utilities

User wwood asked the Programming forum "what the current state is and what the future is for GNU utils like grep, sed, etc. when it comes to multiprocessing."

He clarified in a follow-up for forum regular proopnarine that he wants to take advantage of his system's multiple processors when running heavy scripts, whether by multithreading or parallelism.

Proopnarine responded that it is possible to divide tasks among multiple CPUs in a bash script, but suggested that a more in-depth answer would be found by consulting the GNU project mailing lists.

1,006 characters, 104 keys

On a more practical level, Moonraker asked how to configure Ubuntu so that he could write Japanese characters with his English keyboard. Shashank Sharma provided a list of links from the Ubuntu community help Web site -- but most of the information they contain applies to other modern Linux distributions as well.

47,035 characters, one guy who doesn't read the language

Andy had almost the opposite problem: he picked up an Asus Eee PC at a good price -- but it was localized for "Chinese, which I don't read. Linux and OpenOffice.org and Firefox as well as everything else are in Chinese. Any help on how to load an English version of the software onto this machine?"

Proopnarine provided a link to an Eee users' HOWTO on the subject, but he and user Lin agreed that the simplest and best solution was to install another Linux distro from scratch, using a USB-attached hard disk or CD-ROM. Sid Jackson supplied a step-by-step guide to that process, which requires knowing how to get access to the Eee's boot menu.

If it's Saturday, these must be unanswered questions

Fresh from his Eee-saving wisdom, Sid Jackson needs help connecting his Linux PPTP VPN client to a Microsoft VPN server. Got the answer?

No? Then maybe you can help Raj. He's writing a custom boot-time application that needs to call xmessage when there's an error. It works fine when run manually, but not when run at startup. Know why?

Speaking of execution, smlefo needs some definitive info on how shell scripts get parsed. Most start with the "hash bang" line that dictates what program should execute the script, like #!/bin/bash. But exactly what's legal there and what isn't remains a mystery. Can you solve it?

Finally, don't be depressed if you lack the encyclopedic knowledge to answer the aforementioned programming problems. You can still feel good about yourself by giving some advice to sonicblaze about his search for an audio loopback tool. He needs to tap audio output from one application and pipe it back out to be captured by another. And if that isn't enough, he needs to do it on a virtual machine. Quick, share your answer now, before he adds yet another wrinkle.

That's all for this week. Remember to post your answers to all of these questions by visiting the linked thread -- not by leaving a comment on this story. And it never hurts to take another look at the forum guidelines before you write.

Share    Print    Comments   

Comments

on Ask Linux.com: IT, Japanese, and crafting bigger and better bash scripts

Note: Comments are owned by the poster. We are not responsible for their content.

bash scripts

Posted by: Anonymous [ip: 207.14.167.161] on July 12, 2008 06:37 PM
I think starting a script with #! establishes a magic number-see 'man magic'.
I learned this long ago when I asked an old-timer: when you tell your shell to execute a file,
how does it know if it's compiled or a script? I think this is the same mechanism
that is used by the 'file' command.

#

Re: bash scripts

Posted by: Nathan Willis on July 12, 2008 09:04 PM
Reminder: you have to post your responses to these questions in the forum threads linked to in the article. They don't contribute when left as comments here.

Thanks,
Nate

#

Re: bash scripts

Posted by: Anonymous [ip: 75.211.34.89] on July 16, 2008 10:10 PM
Specifically there's a part of the kernel that detects the executable file type of any filename/path which is passed to the execve() system call.

This characterization: ELF, a.out (obsolete), or script (starts with a #! "shebang"), or (optionally) "misc" then triggers different execution functions
binfmt_* prefixed names in the kernel sources).

If you search the sources you can read the code: <a href="http://www.tamacom.com/tour/kernel/linux/cgi-bin/global.cgi?pattern=binfmt_*&id=&type=path">http://www.tamacom.com/tour/kernel/linux/cgi-bin/global.cgi?pattern=binfmt_*&id=&type=path</a>
for starters.

#! (shebang) lines are processed by binfmt_script which attempts to execute whatever the first argument after the #! line points to, passing any arguments (usually -f for csh and awk scripts, for example) and provides it with an open file descriptor that contains the rest of the contents of the script. The "#" prefix is used as a "comment" more most scripting languages so the interpreter naturally will skip the shebang line as it would any other comment.

You can also strace an instance of the shell ... running a command like: strace -o /tmp/learnshebang.strace sh -c '~/bin/myscript.sh' ... to see how the shell handles the processing at a system call level.

Oddly there are other things that can happen. For example under some versions of csh (tcsh?) I've seen cases where a script with no #! line was still properly executed. After my initial surprise I determined that this shell would attempt to execute the command (possibly a script) and if that failed it would then open the file (in a subshell) and try to process it as the text of a csh script. I won't guarantee that this will work in any current version of csh; I'm just pointing out that I saw it once.

Jim Dennis

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya