Wow I am such a newb, but I won't get any better at this unless I dive in, so here is the question in full that I am having trouble with and I'm sure you can all get a good laugh at:

Write a shell script called nbin. First the script changes to the home directory. Then if there is a bin directory under the current directory, display the message bin has XX files". (Note: the XX will be substituted with the actual number of files in your bin directory)

So far I have done:
vi nbin
#!/bin/bash
PATH=/bin:$HOME/bin





Gosh I am really struggling with these basics.

Any help would be greatly appreciated.

No wonder you're having so much trouble. Try using a more efficient editor than "vi".

I won't write the script for you, but here is what it needs to do:

1. Don't reset your path -- that's the wrong approach. So erase the one working line you typed into in your script.

2. Use the "cd" command (plus an argument) to change to your home directory.

3. Test for the presence of a "bin" directory.

4. If there is such a directory, list the files within it, but capture the list and count the lines that were created by files.

5. Print out how many lines were caused by files (not directories), and that's your result.

Sounds like you'll need
http://rute.2038bug.com/index.html.gz
http://tldp.org/LDP/Bash-Beginners-G...tml/index.html

They should get you started.

Welcome to LQ


There's nothing wrong with vi/vim; it's a very efficient editor.
It's also pretty much guaranteed to exist on any *nix system, not always the case for the others, especially GUI editors.
Best is of course subjective; whatever suits you.

Thanks for the heads up on the vi, it's what we are learning with in class.

I am taking this all online so I don't feel I am getting to ask the really stupid questions I normally would if it was in class, so thanks for letting me bring them here.

so perhaps:

cd nbin > home

is at least the right path?

Thank you! I think I can already tell this is easier for me to read than my professor's writing style.

Try reading those links first, then just mess about with the basic cmds

ls

cd

wc

Use the manual pages:

man ls
man cd
man wc

or see them here
http://linux.die.net/man/


Edit: ok we're cross-posting; I'll leave you to it for a while.

Easier to play around with the commands at a command line to see what they do and familiarise yourself with them. Once you have found a sequence of commands that work it's a small next step to create the nbin script containing them and test it. Good general technique to break a big problem into bite-size chunks.

I would have objected to this view using vi, but I couldn't remember how to get vi to switch between its exclusive and cryptic move-cursor, insert-text, delete-text and select-text modes, each of which requires the user to remember the appropriate multiple command keystrokes as well as exit one mode before entering another.

I remind users that "nano" is available on most Linux distributions, precisely because vi is the only alternative and is incredibly inefficient. Nano, in spite of being a CLI editor, lives in the 21st century -- it takes advantage of the fact that modern computers display on glass terminals, not paper (the original reason for vi's weird behavior).

If you are a historian or a masochist, definitely ... use vi. If you want to get something done in a finite time interval, use nano.

Oh, no! Editor wars!

For nano is well-suited to casual use whereas vi needs a lot of learning but is very functional after doing that learning. nano is a great alternative to vi when the /usr file system is not mounted!

One of the great things about editor wars is that few people are masters of more than one editor so can give a balanced appraisal of the relative merits, of strengths and weaknesses, of suitability for particular tasks.

Why doesn't everyone just use the editor of their choice?

vi/vim is a perfectly acceptable text editor, and I'm sure your favorite editor is equally acceptable.

I personally like (prefer) vi but you are entitled to your opinion

you've probably learned vim, which is in some distributions a soft link from vi to vim.
using vi today (the old version), is a waste of time.


p.s,
I'm a heavy vim user.

Yes -- I agree that we all should know how to use an abacus before daring to express an opinion about its merits compared to a spreadsheet. And before offering an opinion about suicide, we each should ... can you guess what's coming next?

I wrote a rather famous program about 30 years ago called "Apple Writer". A friend who had only used vi tried it and, in spite of the fact that it was running on a computer with the processing power of a blender, almost wet his pants. He simply hadn't realized you could add text, remove text, copy and paste, and move the editing cursor around without explicitly changing control modes for each and every one of these actions.

Everyone is entitled to his personal tastes. But newbies should not be steered toward vi without first being informed that it is a historical artifact of a bygone era, specifically designed to avoid wasting paper while being used on a paper-roll teletype machine.

One the other hand, some ingenious mechanics have recently recreated Babbage's Difference Engine, never fully realized in Babbage's lifetime. So I guess there's a place for vi.

I would agree that newbie's should not be forced to learn vi as the only option for text editing. After all it is not the most intuitive text editor.

The teacher should introduce nano, kate or gedit as these would be much easier to get to grips with.

After all the intention is to write a script, it shouldn't matter what editor is used so the student should be free to use what they would feel most comfortable with.

As for suicide... I have already decided that it's not for me (I know, I never tried it or anything!)