[Sussex] Label and partition external hard drive

[Desmond Armstrong]

  On 25/02/11 10:24, Steven Dobson wrote:
> Hi Desmond
>
> Hope you don't mind by I posted this back to the list as I think you
> replied (rather than "Reply All") to the copy I sent to you directly.
>
> On 25/02/11 08:32, Desmond Armstrong wrote:
>>   On 25/02/11 00:52, Steven Dobson wrote:
>>> On 25/02/11 00:01, Desmond Armstrong wrote:
>>>>    On 24/02/11 14:16, Alex Harrington wrote:
>>>>>> Sorry, Desmond, I know GUI is "easier" but I want:
>>>>> That's all fair enough, but if it were me I'd be using a gparted or
>>>>> partedmagic live CD and have the job done in 15 minutes.
>>>>>
>>>>> I agree it's good to understand the basics, but gparted will show you
>>>>> roughly what it's doing so you'll get the general idea.
>>>> To be honest when one has a GUI one can work faster.
>>> I'm sorry but I have to take issue with this.  *Some* things are quicker
>>> in GUI-land, some are quicker in CLI-land.  Which one is better depends
>>> mostly on the task at hand.
>>>
>>> By knowing both you place yourself in the best position to get the job
>>> done quickly and efficiently.
>> This I certainly advocate.
>>
>>> Today I used GUI tools to download a torrent file, then download the
>>> file I wanted and then a burn it to a blank CD.  But each stage
>>> transition I had to sit there and action the next.
>>>
>>> If I had done it with the CLI I could have written all three task
>>> commands at one time and then gone away and down something much more
>>> interesting.
>>>
>>> Horses for courses.
>>>
>>> The power of the CLI comes from it's ability to script.  Whether that is
>>> an adhoc script written once on the command line or more formally in a
>>> script file.
>>>
>>> One task, as a coder, I do a lot is go looking for code examples in
>>> other code files.  Here the command line wins hand down compared with
>>> any GUI tool I've seen.  I can find(1) files based for a file name
>>> pattern.  Then look within them [grep(1)] for string matches.
>>>
>>> Here's how you look for Java programs that use the JLabel class.
>>>
>>>     $ find . -name \*.java | xarg    grep -w JLabel
>>>
>>> But if you want to look for Java files that use the JLabel class and
>>> also make use of the setText() method:
>>>
>>>     $ file . -name \*.java | xarg grep -lw JLabel | xarg grep setText
>>>
>>> So long as I can think of a way of scripting it I can write a script.
>>> But for GUI uses you are reliant on the GUI developer providing the
>>> facility.  If there is no "find" function in your editor then you can't
>>> quickly find the text you're looking for.
>>>
>>>> At the same time
>>>> one does need to aware of what it is doing. Our difficulty is that we
>>>> are constantly learning new procedures, which is good, but one should
>>>> avoid taking too much time to do a once off. There are just too many
>>>> things that we have to do.
>>> I would like to remind people that if you don't understand and can
>>> control a computer it will control you!  Computer programs now control
>>> our lives.  Whether your shopping at Tescos or driving your car there is
>>> a computer involved somewhere.  So you better be the one in control.
>> Steve, Thank you for putting those comments.
>> The problem for many of us is that we do not sufficiently understand CLI
>> and therefore do resort to available GUIs written by other (experts). A
>> GUI is, after all only a front end (and encapsulation of somebody else's
>> skill) for a CLI script.
>>
>> How about an illustrated presentation of CLI - Steve?
> I would be happy to do so next time I attend a moot.  And I do intend to
> attend, they just never seam to fall right these days.
>
> But my problem is that I don't really know how to pitch such a talk.
> It's taken me years to build up the experience I have.  I did it by
> reading the man pages, the odd tip here and there and by experimentation.
>
> I think just a look at basic commands would be a) rather boring, and b)
> not that useful.  The power of the CLI comes from its ability to string
> commands together.  To take the output from one command and pass it on
> to the next.  But to present that would require a basic understanding of
> some of the simple CLI commands.

Thanks Steve for reposting to the list.

I have an idea for you to present.
What I think would be very helpful is to choose some fairly small CLI 
function and then to build perhaps using Python some sort of GUI for it.
In this way we can appreciate the build up of these functions.

I think this sort of presentation coming from somebody well versed in 
the CLI such as yourself would be very instructive. It would also be 
very helpful to those who are not continuously doing CLI and 
consequently will normally be quite error prone.
> Steve