Hacker News Reader

I'm curious. So you think, this may work as an argument? You think that if I tell my parents this, they'll suddenly start using the command line?

Let me tell you how it works now:

I've installed a download addon for them. Because they have no idea and before they install crap, I'll do it for them.

I did not explain anything nor did I tell them that I did install that addon.

They automatically clicked the red "download" icon under every youtube video they watch and it downloads the video.

So short: 1 step.

This is userfriendly and easy.

> You think that if I tell my parents this, they'll suddenly start using the command line?

Probably not, but that doesn't really matter as it was never the intention (if it were, there's probably a better place to write it than Hacker News).

I was offering software developers a perspective which demonstrates that the GUI/CLI distinction is mostly artificial, and that a CLI doesn't automatically mean "hard to use". After all, as others have pointed out, people managed just fine on DOS back in the day (where "managed just fine" == "shouting at machine for not doing things right", just like today).

> This is userfriendly and easy.

I don't like applying the phrase "userfriendly" to a piece of software, as it depends just as much on the user.

For example, I'm a user of youtube-dl, and I find it incredibly userfriendly: when I use it in scripts, I just write "youtube-dl" followed by flags for the appropriate behaviour. In contrast, your solution sounds really unfriendly to me. First my script would need to open a browser, and since the downloader is part of an addon, I wouldn't be able to use PhantomJS like I usually would. Instead, I'd probably have to go off and learn Selenium, assuming that Selenium drivers can use browser addons? If not, I might have to write a custom XUL app (not done that in a while!), and make sure it's compatible with the addon. Does XUL even work on a headless machine (in my case, RaspberryPi with SSH access)?

You are of course right with the part about user-friendliness but you do realize that most of the internet population did not understand what you tried to say with most of the sentences? ;)

So yes, it depends on the users just as well as your target group.

I'm not sure what your assumption that the difference is mostly artificial bases on since just the difference in the physical act is already overwhelming.

You missed a couple steps at the beginning there:

- Select browser icon

- Double click browser icon

- Click into search box

- Type "youtube"

- Disregard suggestions, hit enter

- Click on first thing that says YouTube

Well, there are lots of ways people interact with browsers; that was just an example. Personally I don't type "google.com", "youtube.com" either, I use Conkeror's web shortcuts.

Still, the point is that it's not much different than running a commandline, e.g. something like:

- Click Gnome Do icon

- type "youtube-dl " and paste URL

- Click the "run" suggestion

- Click on Home launcher

- Watch filename until ".f123." bit disappears from the extension

Yes. This exactly. I know many that don't type in url or even search on YouTube. They just click around. One time a family member asked if all the videos after they watched mine(I sent direct link) were mine as well. They apparently watched 5+ videos thinking they were mine but just happened to be displayed in sidebar and other.

>youtube-dl actually has quite sane defaults

not really, if you copy url of a clip in a playlist it will start downloading WHOLE playlist :(

As it was pointed out the first time youtube-dl was on Hacker News, our user base seems to be split regarding that behavior. When you copy a URL from a playlist, the URL includes both the video id and the playlist id.

Some people want to download the whole playlist when passing a URL from one of the videos (because otherwise it's hard to get an URL that contains just the playlist). Some other people just want to download the video they are currently watching.

That's why we have the --no-playlist option, which you can use and even stick in the configuration file. There's also --yes-playlist to override the configuration file if you need to.

Why not drop to a "did you want the playlist, or just this video?" prompt?

Side-benefit: force care to be taken to be explicit if used in a script.

Personally, without reading any docs the first thing I did was paste in just a video ID (i.e. not the entire URL) so it seems natural to me that including both would be ambiguous.

> Why not drop to a "did you want the playlist, or just this video?" prompt?

Introducing breaking changes like this are no longer an option once your program has more than 5 users.

In addition, well-behaved command line programs aren't supposed to gratuitously prompt for input anyway.

It's debatable whether that should be the default or not; compare it to, say, printing diagnostic info by default and requiring a special `--download` option.

One thing I always change from the default behaviour is video quality: by default it wastes a ton of bandwidth and disk space getting "HD" versions. I can understand why that's the default, but I don't particularly care about resolution, as it's a pretty negligible contributor to quality compared to the actual content of the video.

I think that's an amazing feature. It does the same thing for Soundcloud playlists.

> youtube-dl actually has quite sane defaults too; e.g. "youtube-dl https://......" will Just Work (TM).

Are you sure that this is true? Starting many updates ago, but continuing into the present (I just updated to 2016.04.06 to be sure), I encountered a weird situation where

    $ ./youtube-dl https://www.youtube.com/watch?v=wbKJt1NQtZE

fails but

    $ ./youtube-dl wbKJt1NQtZE

works. I have no problem with the second working, but don't understand why the first fails. It seems to be fine for other video services; only YouTube requires this URL-processing step.

    $ youtube-dl https://www.youtube.com/watch?v=wbKJt1NQtZE
    [youtube] wbKJt1NQtZE: Downloading webpage
    [youtube] wbKJt1NQtZE: Downloading video info webpage
    [youtube] wbKJt1NQtZE: Extracting video information
    [youtube] wbKJt1NQtZE: Downloading MPD manifest
    WARNING: Requested formats are incompatible for merge and will be merged into mkv.
    [download] Destination: True Detective - My Least Favorite Life - Lera Lynn Scene-wbKJt1NQtZE.f136.mp4
    [download]  19.3% of 35.60MiB at  1.51MiB/s ETA 00:18

Seems to work for me. I always double-quote the parameter anyway (I never trust the shell to handle my strings...)

I just tried `youtube-dl wbKJt1NQtZE` and that works too. I didn't know the "v" parameter could be given like that!

In case anyone else hits this (admittedly very specific) problem, nathyong (https://news.ycombinator.com/item?id=11461326 )'s suggestion, and a subsequent USE (http://unix.stackexchange.com/questions/276731/shell-eating-...) question, made it clear that my issue is that I had some time turned on `nullglob`, so `https://www.youtube.com/watch?v=wbKJt1NQtZE ` was being taken as a very strange, certainly non-matching, glob.

Very strange. Perhaps it's some setup- or platform-dependent thing; I will file an issue. Thanks for checking!

EDIT: Very strange; I thought I'd give a try to what seemed a throwaway comment in your post, about quoting the string, and that fixed it. Thanks!

Without the double quotes (which seemed to be unnecessary for you), I still get:

    $ youtube-dl https://www.youtube.com/watch?v=wbKJt1NQtZE
    Usage: youtube-dl [OPTIONS] URL [URL...]

    youtube-dl: error: You must provide at least one URL.
    Type youtube-dl --help to see a list of all options.

I guess that some alias is grabbing some part of the URL string.

It's possible your shell has some kind of regular expression magic enabled that is eating the '?' and the '=' characters:

  $ echo youtube-dl https://www.youtube.com/watch\?v\=wbKJt1NQtZE
  youtube-dl https://www.youtube.com/watch?v=wbKJt1NQtZE
  
  $ echo youtube-dl https://www.youtube.com/watch?v=wbKJt1NQtZE
  zsh: no matches found: https://www.youtube.com/watch?v=wbKJt1NQtZE

Interesting! It seems that my `echo` is eating any substrings involving `?`.

    $ bash --version
    GNU bash, version 4.3.42(1)-release (x86_64-apple-darwin13.4.0)
    Copyright (C) 2013 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

    This is free software; you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.

    $ echo a ? = =?
    a =

> I can understand why many people will avoid using commandlines. The part I don't understand is how they're quite comfortable when those commandlines are surrounded by "Forward", "Back", "Stop" and "Reload" buttons; or when they have an "I'm feeling lucky" button underneath.

Are you sure you apprehend the differences between the look and feel of a browser and that of a command line?

So then someone should create a dynamic hybrid console-browser.

Take, Chrome, flip it such that the input bar is on the bottom, and allow it to display console output as HTML.

Or, hell, keep it the way it is and just run the console HTML downward; why maintain the current terminal layout at all...