Command-line power

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, May 10, 2008.

  1. The difference between a command line and a GUI is that the command line
    inherently allows you to compose a sequence of simpler actions into a more
    complex action that can be invoked just as easily as the simpler ones,
    whereas in a GUI you cannot do anything that the GUI designers did not
    originally envisage.

    Consider a simple example: listening to streaming radio over the Internet.
    On my Eee, I can enter a URL into the GUI-based SMPlayer, or I can type it
    into a command line. However, suppose I'm listening to the news on National
    Radio, and I want to skip the sports section, but I don't want to lose the
    weather report that comes after. As soon as I hear "and now, here's
    sport..." I stop the player, and enter the following command:

    sleep 90; mplayer mms://204.61.215.51/rnz-natrad

    Now I can happily spend the next minute and a half checking up on my
    favourite news websites, reading USENET or whatever, and the streaming
    playback will automatically resume around the last few seconds of the
    sports news, or within the promo that follows.

    How's that for efficient use of your time. :)
    Lawrence D'Oliveiro, May 10, 2008
    #1
    1. Advertising

  2. Lawrence D'Oliveiro

    Gordon Guest

    On 2008-05-10, sam <> wrote:
    > Lawrence D'Oliveiro wrote:
    >> The difference between a command line and a GUI is that the command line
    >> inherently allows you to compose a sequence of simpler actions into a more
    >> complex action that can be invoked just as easily as the simpler ones,
    >> whereas in a GUI you cannot do anything that the GUI designers did not
    >> originally envisage.
    >>
    >> Consider a simple example: listening to streaming radio over the Internet.
    >> On my Eee, I can enter a URL into the GUI-based SMPlayer, or I can type it
    >> into a command line. However, suppose I'm listening to the news on National
    >> Radio, and I want to skip the sports section, but I don't want to lose the
    >> weather report that comes after. As soon as I hear "and now, here's
    >> sport..." I stop the player, and enter the following command:
    >>
    >> sleep 90; mplayer mms://204.61.215.51/rnz-natrad
    >>
    >> Now I can happily spend the next minute and a half checking up on my
    >> favourite news websites, reading USENET or whatever, and the streaming
    >> playback will automatically resume around the last few seconds of the
    >> sports news, or within the promo that follows.
    >>
    >> How's that for efficient use of your time. :)

    >
    > Do you really do that ?


    Some do, and more. Now how is you mind, blown
    Gordon, May 10, 2008
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    Gordon Guest

    On 2008-05-10, Lawrence D'Oliveiro <_zealand> wrote:
    > The difference between a command line and a GUI is that the command line
    > inherently allows you to compose a sequence of simpler actions into a more
    > complex action that can be invoked just as easily as the simpler ones,
    > whereas in a GUI you cannot do anything that the GUI designers did not
    > originally envisage.


    Envisage, I would say chose not to include. For is it not possible for a GUI
    to include *every* CLI command, should the programmer so decide to make it
    so?

    Read, there are some switches of the the command line which will never be
    used by most of the users in a blue moon. The GUI programmer leaves them
    out.

    Exception to the rule is MS, who programmers pack in so much stuff into the
    GUI that most of it users never use most of the options.

    For this version of the programme has more, so you *must* but it.
    Gordon, May 10, 2008
    #3
  4. In article <>, Gordon did write:

    > For is it not possible for a GUI to include *every* CLI command, should
    > the programmer so decide to make it so?


    If you tried to do this, the GUI would become unwieldy long before you had
    come anywhere close to including everything. And even then, you couldn't do
    it. For instance, how would you implement a GUI equivalent
    to "$(...)"--substituting the output of one command as parameters to
    another?
    er
    Lawrence D'Oliveiro, May 10, 2008
    #4
  5. In article <>, Don Hills did write:

    > It's not a fault of GUIs, though - more a fault of the deigner/programmer.


    It is a fundamental limitation of GUIs--you simply cannot put in every
    single function that users might need.

    Here's another example: creating a ZIP archive from a bunch of files. How
    ways does your ZIP utility let you select files? What happens when they're
    not enough?

    The open-source command-line zip utility doesn't provide very complicated
    ways to select files. But then, it doesn't need to. Instead, you have
    the "find" command, which is a general-purpose utility whose sole purpose
    is to select files according to various criteria and feed their names to
    something else. And if its built-in functions aren't enough, it also has
    the ability to use external programs in its filtering criteria.

    For instance, zip up all .c files within the current directory and all its
    subdirectories that were modified within the last 7 days:

    zip newsource.zip $(find . -name \*.c -mtime -7 -print)

    Zip up all files containing the string "INCLUDEME":

    zip included.zip $(find . -exec grep -Fq INCLUDEME {} ';' -print)

    It's all about tools that are not necessarily very powerful individually,
    but that can be combined in very powerful ways.
    Lawrence D'Oliveiro, May 10, 2008
    #5
  6. In article <>, Brian Mathews did
    write:

    > So how is this all possible for the Average computer uses..


    You mean, the Dimdows users who are expected to be able to handle Registry
    edits?
    Lawrence D'Oliveiro, May 10, 2008
    #6
  7. In article <>, Brian Mathews did
    write:

    > On Sat, 10 May 2008 17:45:39 +1200, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    > For instance, how would you implement a GUI equivalent
    >>to "$(...)"--substituting the output of one command as parameters to
    >>another?

    >
    > But do we need to..
    >
    > CLI is for Nerds, not Real People


    Well, on the one hand you've got your minimum-wage drones in their dead-end
    McJobs, having done some Tech course on "Word and Excel" or something,
    mindlessly clicking away at the same tasks over and over.

    And on the other hand you've got someone who's spent a few minutes thinking
    about how to organize things more efficiently, and is able to sit back and
    just watch the computer does what it does best--the mindless, repetitive
    stuff.

    Which type would you rather be? It's your own choice.
    Lawrence D'Oliveiro, May 10, 2008
    #7
  8. In article <q/>, Don Hills did write:

    > There don't appear to be enough people in NZ who know what PuTTY is.


    It's a tool for those restricted to OSes too poor to run proper SSH. :)
    Lawrence D'Oliveiro, May 10, 2008
    #8
  9. In article <482578a1$>, sam did write:

    > Yup thats what employers are crying out for these days, geeks that can
    > pause mplayer from the console.


    OK, here's another actual work-related multimedia example.

    A client of mine wants to pull high-def video footage off these JVC cameras
    with hard drives, to do some workflow processing on them. If you plug in
    the camera via USB, it shows up as a hard drive, with the video as a
    sequence of MPEG-2 files. One problem: the camera insists on starting a new
    file every 18 minutes of recording, so a long clip gets broken up into a
    sequence of segments. Whereas we really want the whole clip in one file.

    Now, the client knows nothing about command-line stuff. So it's my job to
    put up a simple GUI menu with an option that says "Import Video". They
    click that, choose the source video directory and destination filename, and
    everything else should happen automatically.

    Enter my favourite multi-purpose multimedia workhorse, FFmpeg. That can
    convert just about any video or audio codec and file format to any other,
    while performing various useful transformations en route. Among its myriad
    of options are a file format called "image2pipe" (just a simple sequence of
    video frames) and a codec called "copy" (which just does a bit-by-bit copy
    without trying to encode or decode anything).

    So, for each video segment file in turn, I can extract the video frames and
    write them to standard output using a command like

    ffmpeg -i srcfile -f image2pipe -vcodec copy -y /dev/stdout

    To concatenate the video from several files, just extract them in turn:

    ffmpeg -i srcfile1 ... ; ffmpeg -i srcfile2 ... etc

    Now I can embed the above sequence in place of the ellipsis in the following
    command:

    ffmpeg -i <(...) -vcodec copy -y dstfile

    and it will create "dstfile" as the concatenation of the video streams
    of "srcfile1", "srcfile2" etc.

    I won't go into the detail of how the audio tracks are similarly processed,
    but putting this all together into a Python script sequence to generate the
    full command line, we get

    ImportCmd = \
    (
    "ffmpeg -v 0 -i <(%(src_video)s)"
    " %(audio_parms)s -i <(%(src_audio)s)"
    " -vcodec copy -acodec %(audio_codec)s -y %(dstfile)s"
    %
    {
    "src_video" :
    "; ".join
    (
    [
    "ffmpeg -v 0 -i %(srcfile)s -f"
    " image2pipe -vcodec copy"
    " -y /dev/stdout"
    %
    {"srcfile" : ShellEscape(SrcFile)}
    for
    SrcFile in SrcFiles
    ]
    ),
    "src_audio" :
    "; ".join
    (
    [
    "ffmpeg -v 0 -i %(srcfile)s"
    " %(audio_parms)s -y /dev/stdout"
    %
    {
    "srcfile" : ShellEscape(SrcFile),
    "audio_parms" : AudioParms,
    }
    for
    SrcFile in SrcFiles
    ]
    ),
    "dstfile" : ShellEscape(DstFile),
    "audio_parms" : AudioParms,
    "audio_codec" : "mp2",
    }
    )

    And all triggered by the click of a single button. :)
    Lawrence D'Oliveiro, May 10, 2008
    #9
  10. In article <48264196$>, sam did write:

    > Lawrence D'Oliveiro wrote:
    >
    >> In article <q/>, Don Hills did write:
    >>
    >>> There don't appear to be enough people in NZ who know what PuTTY is.

    >>
    >> It's a tool for those restricted to OSes too poor to run proper SSH. :)

    >
    > openssh runs fine in cygwin


    Ah, Cygwin ... Viagra for Windows. :)
    Lawrence D'Oliveiro, May 11, 2008
    #10
  11. Lawrence D'Oliveiro

    Craig Shore Guest

    On Sun, 11 May 2008 10:08:20 +1200, sam <> wrote:

    >Lawrence D'Oliveiro wrote:
    >> In article <482578a1$>, sam did write:
    >>
    >>> Yup thats what employers are crying out for these days, geeks that can
    >>> pause mplayer from the console.

    >>
    >> OK, here's another actual work-related multimedia example.
    >>
    >> A client of mine wants to pull high-def video footage off these JVC cameras
    >> with hard drives, to do some workflow processing on them. If you plug in
    >> the camera via USB, it shows up as a hard drive, with the video as a
    >> sequence of MPEG-2 files. One problem: the camera insists on starting a new
    >> file every 18 minutes of recording, so a long clip gets broken up into a
    >> sequence of segments. Whereas we really want the whole clip in one file.
    >>
    >> Now, the client knows nothing about command-line stuff. So it's my job to
    >> put up a simple GUI menu with an option that says "Import Video". They
    >> click that, choose the source video directory and destination filename, and
    >> everything else should happen automatically.
    >>
    >> Enter my favourite multi-purpose multimedia workhorse, FFmpeg. That can
    >> convert just about any video or audio codec and file format to any other,
    >> while performing various useful transformations en route. Among its myriad
    >> of options are a file format called "image2pipe" (just a simple sequence of
    >> video frames) and a codec called "copy" (which just does a bit-by-bit copy
    >> without trying to encode or decode anything).
    >>
    >> So, for each video segment file in turn, I can extract the video frames and
    >> write them to standard output using a command like
    >>
    >> ffmpeg -i srcfile -f image2pipe -vcodec copy -y /dev/stdout
    >>
    >> To concatenate the video from several files, just extract them in turn:
    >>
    >> ffmpeg -i srcfile1 ... ; ffmpeg -i srcfile2 ... etc
    >>
    >> Now I can embed the above sequence in place of the ellipsis in the following
    >> command:
    >>
    >> ffmpeg -i <(...) -vcodec copy -y dstfile
    >>
    >> and it will create "dstfile" as the concatenation of the video streams
    >> of "srcfile1", "srcfile2" etc.
    >>
    >> I won't go into the detail of how the audio tracks are similarly processed,
    >> but putting this all together into a Python script sequence to generate the
    >> full command line, we get
    >>
    >> ImportCmd = \
    >> (
    >> "ffmpeg -v 0 -i <(%(src_video)s)"
    >> " %(audio_parms)s -i <(%(src_audio)s)"
    >> " -vcodec copy -acodec %(audio_codec)s -y %(dstfile)s"
    >> %
    >> {
    >> "src_video" :
    >> "; ".join
    >> (
    >> [
    >> "ffmpeg -v 0 -i %(srcfile)s -f"
    >> " image2pipe -vcodec copy"
    >> " -y /dev/stdout"
    >> %
    >> {"srcfile" : ShellEscape(SrcFile)}
    >> for
    >> SrcFile in SrcFiles
    >> ]
    >> ),
    >> "src_audio" :
    >> "; ".join
    >> (
    >> [
    >> "ffmpeg -v 0 -i %(srcfile)s"
    >> " %(audio_parms)s -y /dev/stdout"
    >> %
    >> {
    >> "srcfile" : ShellEscape(SrcFile),
    >> "audio_parms" : AudioParms,
    >> }
    >> for
    >> SrcFile in SrcFiles
    >> ]
    >> ),
    >> "dstfile" : ShellEscape(DstFile),
    >> "audio_parms" : AudioParms,
    >> "audio_codec" : "mp2",
    >> }
    >> )
    >>
    >> And all triggered by the click of a single button. :)

    >
    >Great
    >And there we have yet another example of an end user using a convenient
    >GUI interface to carry out a task defined by a programming geek nerd,
    >and not the utility of a CLI to the end user.
    >You certainly have strong geek foo and can piss a long way up the CLI wall.


    Or alternatively he could drag and drop the individual video files
    onto a timeline in a video editing program (people like to see it
    doing what they think it's doing) and hit the export button to save it
    to one file.
    Craig Shore, May 11, 2008
    #11
  12. In article <>, Craig Shore did
    write:

    > Or alternatively he could drag and drop the individual video files
    > onto a timeline in a video editing program (people like to see it
    > doing what they think it's doing) and hit the export button to save it
    > to one file.


    Yeah, only about 15 of them to do at a time, not considering the quality
    loss due to recompression...
    Lawrence D'Oliveiro, May 11, 2008
    #12
  13. Lawrence D'Oliveiro

    EMB Guest

    Don Hills wrote:
    >
    > It's a tool for those restricted by corporate edict(*)


    Do you work for IBM Don?
    EMB, May 11, 2008
    #13
  14. On May 11, 8:37 pm, Collector€NZ <> wrote:
    > EMB wrote:
    > > Don Hills wrote:

    >
    > >> It's a tool for those restricted by corporate edict(*)

    >
    > > Do you work for IBM Don?

    >
    > Corp edict has its place.
    >
    > At work I have a bunch of users (Shift workers) who bring in VLC
    > Portable media player on USB drives along with divx movies so they can
    > watch them on night shift, trouble is that the VLC portable creates
    > large temp files on the c:\windows\temp and doesnt remove them. Nett
    > result after a while the Hard disk fulls up and people cant log on
    > anymore since there is no space left to download there profile.
    >
    > They can get away with this as the VLC player doesnt require install
    > (Install needs local admin and that is locked down) so really the only
    > way to control it is Corp edict and threats


    Disable the USB ports in the BIOS.
    Hamish Campbell, May 11, 2008
    #14
  15. Lawrence D'Oliveiro

    EMB Guest

    Hamish Campbell wrote:
    > On May 11, 8:37 pm, Collector€NZ <> wrote:
    >> EMB wrote:
    >>> Don Hills wrote:
    >>>> It's a tool for those restricted by corporate edict(*)
    >>> Do you work for IBM Don?

    >> Corp edict has its place.
    >>
    >> At work I have a bunch of users (Shift workers) who bring in VLC
    >> Portable media player on USB drives along with divx movies so they can
    >> watch them on night shift, trouble is that the VLC portable creates
    >> large temp files on the c:\windows\temp and doesnt remove them. Nett
    >> result after a while the Hard disk fulls up and people cant log on
    >> anymore since there is no space left to download there profile.
    >>
    >> They can get away with this as the VLC player doesnt require install
    >> (Install needs local admin and that is locked down) so really the only
    >> way to control it is Corp edict and threats

    >
    > Disable the USB ports in the BIOS.


    That used to work brilliantly, but in the modern age of USB keyboards
    and mice it is often no longer an option.
    EMB, May 11, 2008
    #15
  16. Lawrence D'Oliveiro

    Craig Shore Guest

    On Sun, 11 May 2008 19:34:43 +1200, Lawrence D'Oliveiro
    <_zealand> wrote:

    >In article <>, Craig Shore did
    >write:
    >
    >> Or alternatively he could drag and drop the individual video files
    >> onto a timeline in a video editing program (people like to see it
    >> doing what they think it's doing) and hit the export button to save it
    >> to one file.

    >
    >Yeah, only about 15 of them to do at a time, not considering the quality
    >loss due to recompression...


    Drag the whole lot in one go then. No need to recompress, the better
    programs don't if they don't have to.
    Craig Shore, May 11, 2008
    #16
  17. Lawrence D'Oliveiro

    Craig Shore Guest

    On Sun, 11 May 2008 20:50:32 +1200, EMB <> wrote:

    >Hamish Campbell wrote:
    >> On May 11, 8:37 pm, Collector€NZ <> wrote:
    >>> EMB wrote:
    >>>> Don Hills wrote:
    >>>>> It's a tool for those restricted by corporate edict(*)
    >>>> Do you work for IBM Don?
    >>> Corp edict has its place.
    >>>
    >>> At work I have a bunch of users (Shift workers) who bring in VLC
    >>> Portable media player on USB drives along with divx movies so they can
    >>> watch them on night shift, trouble is that the VLC portable creates
    >>> large temp files on the c:\windows\temp and doesnt remove them. Nett
    >>> result after a while the Hard disk fulls up and people cant log on
    >>> anymore since there is no space left to download there profile.
    >>>
    >>> They can get away with this as the VLC player doesnt require install
    >>> (Install needs local admin and that is locked down) so really the only
    >>> way to control it is Corp edict and threats

    >>
    >> Disable the USB ports in the BIOS.

    >
    >That used to work brilliantly, but in the modern age of USB keyboards
    >and mice it is often no longer an option.


    You can disable USB storage only under XP

    change the registry key setting from 3 to 4 on
    HKLM\System\CCS\Services\Usbstor
    then change the rights to that key so nobody can re-enable them.

    Or use group policy

    http://tinyurl.com/8ta6s
    Craig Shore, May 11, 2008
    #17
  18. In article <>, Craig Shore did
    write:

    > On Sun, 11 May 2008 19:34:43 +1200, Lawrence D'Oliveiro
    > <_zealand> wrote:
    >
    >>In article <>, Craig Shore did
    >>write:
    >>
    >>> Or alternatively he could drag and drop the individual video files
    >>> onto a timeline in a video editing program (people like to see it
    >>> doing what they think it's doing) and hit the export button to save it
    >>> to one file.

    >>
    >>Yeah, only about 15 of them to do at a time, not considering the quality
    >>loss due to recompression...

    >
    > Drag the whole lot in one go then.


    What about getting them in the right order?
    Lawrence D'Oliveiro, May 11, 2008
    #18
  19. In article <4826c8ed$>, Collector€NZ did write:

    > Hamish Campbell wrote:
    >
    >> On May 11, 8:37 pm, Collector€NZ <> wrote:
    >>> EMB wrote:

    >>
    >> Disable the USB ports in the BIOS.

    >
    > Got great tools for disabling all sorts of ports including USB but it
    > isn't that simple. Many machines in my domain need the USB ports for
    > instruments and devices


    Can't you set up udev rules that will block access to USB storage devices
    while allowing other things?
    Lawrence D'Oliveiro, May 11, 2008
    #19
  20. In article <4826c948$>, Collector€NZ did write:

    > Not that simple too many machines need the usb ports and the data
    > grabbers are essentially USB storage devices as far as the OS is concerned


    Yes, but they'll have different serial numbers, manufacturer/model codes,
    that kind of thing. In udev you should be able to set up rules to
    discriminate between them on that basis.
    Lawrence D'Oliveiro, May 11, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Silverstrand
    Replies:
    0
    Views:
    952
    Silverstrand
    Apr 17, 2006
  2. Mike Rahl
    Replies:
    6
    Views:
    2,325
    Walter Roberson
    Dec 12, 2006
  3. chuckcar
    Replies:
    11
    Views:
    9,438
    §ñühw¤£f
    Apr 21, 2009
  4. Evan Platt
    Replies:
    1
    Views:
    865
    John Holmes
    Apr 18, 2009
  5. §ñühw¤£f
    Replies:
    2
    Views:
    1,505
    §ñühw¤£f
    Apr 19, 2009
Loading...

Share This Page