Hacker News Reader

Ooh, I didn't know about `mp3splt`! This is super helpful, thanks for posting it.

> It's something I strongly recommend: store off-used CLI calls in your notes/personal wiki.

All of my bash commands from any terminal get piped into a separate, unified history file, copying some setup I read about in a blog a long time ago. It's an easy, dumb setup that just works. I've been using it for years without any performance problems, and if I ever get any, I can just archive the current text file and start over with a fresh one.

Having access to past commands is really handy and has saved my butt multiple times.

  log_bash_persistent_history()
  {
      [[
          $(history 1) =~ ^\ *[0-9]+\ +([^\ ]+\ [^\ ]+)\ +(.*)$
      ]]
      local date_part="${BASH_REMATCH[1]}"
      local command_part="${BASH_REMATCH[2]}"
      if [ "$command_part" != "$PERSISTENT_HISTORY_LAST" ]
      then
          echo $date_part "|" "$command_part" >> ~/.persistent_history
          export PERSISTENT_HISTORY_LAST="$command_part"
      fi
  }

  # Stuff to do on PROMPT_COMMAND
  run_on_prompt_command()
  {
      log_bash_persistent_history
  }

  PROMPT_COMMAND="run_on_prompt_command"
  HISTTIMEFORMAT="%d/%m/%y %T "
  alias phgrep='cat ~/.persistent_history|grep --color'
  alias hgrep='history|grep --color'

Thanks for this. This solves my tmux / history problem. Commands from one open terminal were not available in the history command for the other terminal, if I had two terminals open.

Too tired to try it and port if necessary yet, but I'd like to ask: does it work on ZSH?

I've never used ZSH, so I don't know.

My instinct says that if you'd run into any problems, it would be with this line:

  PROMPT_COMMAND="run_on_prompt_command"

Maybe ZSH has a different API? Again though, I've always just used bash, so you'd have to try it and see.

You can even do fun things like transcode a stream into a format that omxplayer can handle and render a video straight onto a Raspberry Pi without having to download it (and without X11)

'omxplayer' '--blank' '--aspect-mode' 'stretch' <(youtube-dl -o - --audio-format m4a --recode-video mp4 'https://www.youtube.com/watch?v=MKNYsKwM6HI')

While I was still using my Raspberry Pi as a "media center", I wrote a small server using tornado that did this via a URL: https://github.com/filmor/rpi-media/tree/master/ytdld

I had a small javascript commandlet in my bookmarks that allowed me to start playback directly from a youtube (or any other youtube-dl supported) page.

You can also do that with the 'Play to Kodi' browser addon.

> To preempt comments saying CLI is too hard for regular people: no, it isn't; they can learn[0]

Hear hear.

It all comes together when the regular person takes a little time to learn the following three truths[0]:

* the output of any CLI command may be redirected to the input of any other CLI command

* the output template of 99% of commands give you structured, predictable JSON data/metadata on which to operate

* 99% of CLI commands have the same sane defaults and are required by the spec to have the same option syntax for flags

* CLI is CLI. Generating a random number in the CLI on OSX is just as safe as doing the same on OpenBSD, Raspbian, QNX, etc.

[0] Three because I'm starting from zero

I plan to make an 'advanced' mode that will allow people to pass custom flags, select file formats etc, especially given the large initial interest. Right now this was mostly a proof of concept and targeted towards nonsophisticated end users but if the project grows those things will definitely land in time, thanks for the suggestions.

No problem & good luck. I'm definitely not a target user, but my mom is. The Electron aspect is a bit painful though manageable, but as long as she could literally download the .exe, and the basic functionality of the product was simple enough (click to open, paste URL, click to save; optionally click to specify some advanced option; no tracking or telemetry whatsoever), I'd happily install it for her. I already installed her a standalone console .exe + ffmpeg, but it's slightly too painful to use[0].

(If you ever happen to grow the project to the point of offering different languages, drop me a line, and I'll give you Polish language translations.)

EDIT: Also consider auto-updates for your application; it would be best if it could update its youtube-dl dependency independently from the app itself. I don't like auto-updates too much (especially when they're forced), but as others point out, youtube-dl and YouTube are in a state of cold war; YouTube downloads tend to magically break every couple of weeks now, which requires users to update the youtube-dl script.

--

[0] - https://www.lesswrong.com/posts/reitXJgJXFzKpdKyd/beware-tri...

Thanks for the input. Yep your mom would definitely be a target user but even for myself the app has been very useful, when you know you have a nice GUI to play with it reduces the cost of doing certain fun projects that require quick downloads so it is nifty for everyone to have in their backpocket, and yes the .dmg for OS X is ready and I'll have an .exe file out relatively soon too.

Auto-update will definitely be a feature it's quite easy with the youtube-dl package I'm using.

First thought on this project: hey, why electron yt-dl works perfectly from the command line, I type the programm, paste the url. Second thought: might be nice for selecting from the myriad of options. Well...

Not everyone is familiar or comfortable with the command line.

A lot of my friends don't use youtube-dl for this exact reason. They end up messaging me, asking me to download files for them.

Why not just create a simple phone number with twilio that they can text a url to and then it fires a script to download that video and upload it to s3 for them? Shouldn’t take more than an hour IMO.

If it wasn't for the copyright infringement this wouldn't be a bad business idea.

One video per day is free - if you want extra "credits" pay for it on the website.

It doesn’t really matter, if you get a dmca takedown just delete that file. But I doubt you will, especially if it’s just your friends hosting it.

Mainly because I actually like talking to my friends, and I'm often interested in whatever video/music they want me to download for them.

I have no desire to automate my interactions with my friends, especially for something that's easy enough for me to do and only takes a minute of my time.

You could just look at the logs to see what kind of stuff they download. And since they know it’s automated they will likely download even more stuff. If you see something interesting then maybe you can start a conversation with them at that point.

There's already a bunch of websites that do this if they can't use youtube-dl -- why are they messaging you when they can literally go to one of these sites and paste the URL in to get the video?

If you’ve trained a computer illiterate person well, they will not go to sketchy ad-ridden websites and download files to their PC and double click them.

Name 1 which works flawlessly. No ads. On a side note, is it possible to port this CLI program to Android or web? My mom needs a downloader and the Firefox ext which I used till now , doesn't work all the time.

install termux, install youtube-dl, define a "handler"-script, share the link with termux

I understand this too, but being on HN, familiarity with the CLI probably can be taken for granted. For all the other people this will stop them from using shady sites, but even some of them might like to have some more options included in such program... For the current feature-level there is 0 reason to do a bloated electron app - just do your 100 lines of code with tray integration for all the major OS (with a GUI) (Java might even have systray integration)

You've just summed up the gui/command line dichotomy.

It's something we could do better at bridging the gap between.

Tbh things like this, a gui front end for a terminal app seem the best way forward. I don't know why they aren't used a lot more in open source, it just seems to match up so much better to the open source model of a random person developing a project and no one taking over when that person loses interest. The front ends are the sexy bits where you get more churn but also more interest. The boring back end doesn't attract, but also doesn't need so much attention.

I suppose you could argue we do it at the library level, I still think there's room to do it at this level also.

You can't script this GUI. You can't use Cron with an interactive GUI. You can't parse stdin/out/err.

Each have their pros and cons. I'd say what makes most sense is a library with frontends (CLI, TUI, GUI, (web)socket, etc)

In this case I wouldn't need a GUI with Electron. All I would need is a Firefox extension for youtube-dl (or the hypothetical library). Why keep reinventing wheel? Hence library.

One annoying thing with CLI is defaults. You might wanna set defaults (in CLI often used in an alias). So I end up managing a large alias list but what if I use more than 1 shell depending on machine? What if the machine does not use Git to sync such files?

"You can't script this GUI. You can't use Cron with an interactive GUI. You can't parse stdin/out/err"

No but you can script the underlying youtube-dl so with the gui front end you get the best of both worlds.

Re defaults, that isn't an inherent shortcoming of terminal apps. Theres no reason why 'youtube-dl url' shouldn't just do the 'right thing'. I agree it's a common problem though.

> Theres no reason why 'youtube-dl url' shouldn't just do the 'right thing'.

The error in your reasoning is that you assume the existence of a singular right thing. Software that attempts to just do the right thing tends to suffer from what I call Overly Clever Syndrome. I hate waiters or store clerks that second-guess my motivations. Why should I like software that does the same?

That said, `youtube-dl $url` will download the pointed-to video in the best available quality, so that's a pretty decent default.

I put 'right thing' in inverted commas because I know how slippery it can be.

Gui apps have defaults too, this isn't a problem unique to terminal apps. I'll go further and say GUI apps suffer more because they tend to design around a default and have many fewer non default options, in the name of being easy to use. Terminal apps on the other hand 'suffer' because they don't make enough assumptions about how it is to be used.

Suffer is very much in inverted commas though, sometimes you want to do that niche thing, and having something that makes no assumptions about how it will be used is great. On the other hand having to read a manpage for the simplest of things is not so great.

> the front ends are the sexy bits

For a lot of people this isn't true.

I think for web developers, making guis is fun (why this is done in electron). For a lot of non web developers, making the actual tool is the fun part. Having to then fiddle around with some gui feels less like programming and more like a chore.

Ok, can we agree that back end and front end appeal to different kinds of people, and the lifespans of front end and backend are different.

Actually I hate doing frontends way prefer to work with serverside code than play with the DOM, but I recognize that a good frontend is super important to the app to allow people to reason about how it works and to help them through the process, but for my 2c I would way prefer to tinker with backend code all day :)

> Tbh things like this, a gui front end for a terminal app seem the best way forward. I don't know why they aren't used a lot more in open source

Elitism. A lot of people in tech have gigantic egos and believe they are better than everyone else because of their arcane knowledge, so they have no desire to see anything become more discoverable or easier to use.

Whereas non-tech people would run around like headless chicken if asked to build anything. Forget discoverability.

It's not an ego issue - I doubt any tech worker is happy when dealing with non-discoverable software as a user. But connecting this experience to building your own software, and learning to design things to be discoverable by default (because in a typical job, if you don't do something right the first time, it probably won't ever be done right), is hard.

I think its more:

A) power users having different priorities to light users. That tool you use every day, you probably use keyboard short cuts, know all the flags. The tool you use once every 6 months, you probably scan the menus and check the man page. Open source tends to be focused more on the power users, mainly because its probably power users that made the thing to start with.

B) open source tends not to be a 'product'. There aren't focus groups and usability testers, the first releases are Alphas and Betas so tend to attract technically minded people that find their way around less discoverable interfaces.

I liked the "Commando" GUI in the Macintosh Programmer's Workshop:

http://school.anhb.uwa.edu.au/personalpages/kwessen/web/soft...

Using it is like pulling up the manpage while typing out a command, but interactive. Once you're done formulating your command, it runs in your worksheet and you can modify it and re-run it if necessary, just like any other command.

Even being someone who uses the CLI, now that I have this app I will probably rarely use the CLI, it's just nicer to see things visually as to be able to reason about them. Also selecting the directory etc is something way more easily done via a GUI than the command line. There's a reason why operating system manufacturers created a GUI and we all use them today, they fit with our brains much more than just using a terminal.

I guess for the ever changing sea (more like the lakes of Google and Vimeo) of video-sites, the backend actually matters a lot... And (this GUI being a prime example- while not really even featureful): most CLI (instead of library...)-wrappers show it. They're a bunch of dialogs for selecting options - wow. I wouldn't care if you propose developing the GUI separately (basically for wrapping any CLI, you could develop a generic wrapper, reading in declarative configs...), but the kind of execution demonstrated here is probably necessiting the installation of 1 GB of electron-crap (say hello to the reusing world of require('shebang-regex'))

You made me realize I accidentally used the worst audio quality all the time.

I thought higher number = higher quality but then I had a look at the manpage again...

I wish the installation was easier. It is reasonable to explain someone to write "youtube-dl -x <link>" to download music from youtube...

But having them installing ffmpeg and python, manually copying some exe to a safe place, and adding that as a enviroment variable really cuts the interest off.

That's because you're using Windows, which is really, really not designed with scripts in mind.

Point to Ubuntu in the Microsoft Store. Python is preinstalled. You may need to install Python's package manager (I'm not sure does it come preinstalled) with "sudo apt install python3-pip". Install it from Python's package manager with "pip3 install youtube-dl".

You could technically skip Python's package manager by just doing "sudo apt install youtube-dl", but updates are slow there, and you really don't want slow updates with this tool ("pip3 install --upgrade youtube-dl"). I'd argue that three commands are way easier to explain than installing two binaries and clicking around far too many times, especially because youtube-dl needs to be updated on a regular basis in order to work properly.

Did you honestly write this down thinking it was remotely any easier?

Then the alternative? Absolutely. The alternative requires finding the latest version of Python, installing it, modifying the environment path, finding the binary for youtube-dl, installing it, and only then figuring out how it works.

"Execute these commands only once and then just type youtube-dl https://example.com. If something breaks, run this command to upgrade the script and retry." If the target audience is someone who you think will feel comfortable doing youtube-dl in a terminal, you may as well point them to the total of three other commands to set things up.

AFAIR youtube-dl had an .exe build, I remember setting it up for my mom; it boiled down to unzipping an archive and telling here to drag URLs onto this icon. And the FFMpeg part; that was a PITA, and something she wouldn't have guessed on her own.

> Windows exe requires Microsoft Visual C++ 2010 Redistributable Package (x86) and does not require Python that is already embedded into the binary.

Yeah, that makes sense. Things have changed since last time I went through that pain.

Funny how I've been using vb, python, perl and bash scripts. Windows for the past 20 years. I suppose that didn't happen?

Why do people who use Linux automatically think you cannot use scripts or there are no scripting languages on Windows?

Might be the use-case for Chocolatey or something like that, if more than just youtube-dl is going to be used in console.

(Dunno which package managers are alright in Windows.)

Chocolatey is the way to go. Once you have it installed, it's just `choco install youtube-dl` and `choco install ffmpeg`.

This is how you get Chocolatey: https://chocolatey.org/install.

Chocolatey also bypasses all the dark parterns of download websites which is a big plus for a non technical user. I wish Microsoft would take it over and integrate it in windows by default.

You're describing the Windows Store.

Except the windows store was the toll protected, limited privilege applications, had to be developed for windows store, rather than a way to download and deploy any msi for major existing software.

I like https://scoop.sh/

    scoop install youtube-dl

I plan to package platform specific FFMpeg with the app especially now given the large initial interest. Then once I package everything for the different platforms via Electron it should be as easy as installing any other application an end-user would install, that's the hope.

snippets.org seems to be some sort of iGaming site. Is there some other site you use for storing snippets?

:) `snippets.org` means that TeMPOraL is using org-mode[0] to organize the content; it's not a website.

However, I would say use Git and just sync your stuff to a public/private Gitlab/Github repo depending on your needs. That's how I organize most of my public configs.

[0]: https://orgmode.org/

Ohhh, right. Thanks! I'm a vi person myself. :)

Sorry for that. 'danShumway is correct - it's a snippet file called snippets.org, i.e. it's written in org-mode.

When composing my comment, I wrote a couple words about Org mode, then realized it's off-topic and deleted them before submitting the comment. I fully intended to leave just "snippets file", but forgot to remove the ".org" part.