I've worked at a shop with a lot of legacy code and a very fragile build environment. The myriad of scripts that source scripts that source other scripts to produce a working build were all written in KSH - as well as the majority of the tools to set up an environment to actually run the software. Since these scripts were intended to be sourced, adding a shebang doesn't solve the issue at all.
Fortunately, zsh can operate in ksh emulation mode [1] so I was able to leverage zsh while I was there to some extent.
The system I worked on there is still being actively used and developed today and still relies on a fragile set of ksh scripts to build and run in certain environments.
Seems to be video-dependent, tried the one you posted, and it seems to fail, but another one "https://www.youtube.com/watch?v=oY4Gz_Axpew" worked with yt-dlp but not youtube-dl.
Guess it's the beginning of the end of watching youtube for me soon.
youtube-dl https://www.youtube.com/watch?v=oY4Gz_Axpew
[youtube] oY4Gz_Axpew: Downloading webpage
[youtube] oY4Gz_Axpew: Refetching age-gated info webpage
WARNING: unable to download video info webpage: HTTP Error 404: Not Found
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/local/bin/youtube-dl/__main__.py", line 19, in <module>
File "/usr/local/bin/youtube-dl/youtube_dl/__init__.py", line 475, in main
File "/usr/local/bin/youtube-dl/youtube_dl/__init__.py", line 465, in _real_main
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 2069, in download
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 808, in extract_info
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 815, in wrapper
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 836, in __extract_info
File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 534, in extract
File "/usr/local/bin/youtube-dl/youtube_dl/extractor/youtube.py", line 1502, in _real_extract
File "/usr/local/bin/youtube-dl/youtube_dl/compat.py", line 2644, in compat_parse_qs
File "/usr/local/bin/youtube-dl/youtube_dl/compat.py", line 2614, in _parse_qsl
AttributeError: 'bool' object has no attribute 'split'
SDL1 can be installed alongside of SDL2. Same with GTK and Qt. I really fail to see the issue here. If a developer of a Qt4 application doesn't feel like updating to Qt5, users can still use the Qt4 version with Qt5 installed in their system. Most Linux distributions still package Qt5, Qt4, Gtk3, Gtk2, Gtk1.2, SDL1.2, SDL2...
On top of that, if a binary-only application really wanted to stand the test of time, it could statically link the libraries.
This doesn't help much when the specific application you want to run is not available in your system because it doesn't ship Qt3 or Qt4 or Gtk1 or whatever (note that AFAIK none of these are shipped anymore in Debian sid) and it also doesn't help much if the application you are trying to run is using a library that, even though it exists in version N, there is already a version N+Y (Y=1, 2, whatever) that essentially provides the same functionality to the application but it is backwards incompatible while providing more functionality to the user that you'd like to use.
To make that last part more clear, imagine a theoretical "libopenfile" library that shows a file dialog, this library in version 1 exposes a function like "open_file(const char* path);" but in version 2 they improved the GUI a bit (e.g. making the dialog make better use of screen real estate, added a create folder button, etc) and changed the function name to "lof_select_file(const char* path);" because arbitrary tidyness reasons and in version 3 they changed the signature to "lof_select_file(const char* path, unsigned flags);" and added the ability to load plugins that could provide more actions for each file in the displayed file list, show overlay icons, etc.
As things are right now, a modern Linux system would need to have all three versions of the library installed - assuming the distribution cared about backwards compatibility to provide all of them instead of the latest and perhaps the previous version - meaning there would be three different libraries providing essentially the same functionality in three slightly different ways. Moreover, and also very important, version 1 applications do not get to use any improvements introduced in version 2 and neither version 1 nor version 2 can use the plugins introduced in version 3 - even though, again, all they want is to show a dialog to choose a file.
The way that would have been done right is for the version 2 of the library to still export the "open_file" function but simply make it call "lof_select_file" and version 3 make a "lof_select_file2" (or "_ex" or whatever, if the reason to not do that is because you dislike the naming, you are part of the problem) that accepts flags and have "lof_select_file" call it with a default set of flags. Then everything would work, from version 1 to version 3 and all applications would get the functionality introduced in subsequent versions (and as a sidenote, no, i wouldn't remove open_file from the header files to encourage using the renamed function since backwards compatibility in source form is very important too - not everyone who gets to compile a piece of code is the developer of that code, or even a developer).
Now the above is a bit of a strawman, but it is exactly the situation you get with Gtk1, Gtk2, Gtk3, Gtk4, Qt1, Qt2, Qt3, Qt4, Qt5, SDL1, SDl2, etc and pretty much most of libraries that you find on a desktop system (notable and thankful - so far - exceptions, being the X11 libraries and... Motif, although that isn't installed by default anywhere so it isn't really something you can rely on).
In a worst case scenario, couldn't you simply bundle a static version of an old library with an old open source app to avoid the problem of a distro dropping old dependencies?
This works when it's only libraries that are changing. As soon as protocols change, you're fucked. Case in point, Wayland. Right now, most Wayland compositors run Xwayland (i.e. an entire X server) under the hood to enable legacy applications without Wayland support to run on them. This will eventually not be supported anymore. Not today, not tomorrow, but maybe in 10 years. Then it's gonna be absolute game over for everything that's compiled against X libraries.
So long as you don't need to "source" any of these POSIX-compliant scripts into your environment... A shebang'd script cannot affect the environment of the parent process
Lucky for you. I have really come to love zsh's sh and ksh emulation features for this very reason. I have worked in various work environments where setting up a build environment or a testing environment required sourcing ksh scripts that sourced even more ksh scripts. The majority of the engineers on these teams would "deal with" ksh for this reason but a few of the "geekier" engineers would set up zsh with ksh emulation in order to work in a more usable shell.
That says nothing about phone numbers, just addresses.
Selling an address updating service to parties that already have your address is not the same as "straight up sell[ing] your phone number when you move."
From the horses mouth:
"The information you supply will be used to provide you with the requested mail forwarding and related services. Please be aware that this service is voluntary, and that requested information is required to provide the service. Collection of information for this service is authorized by 39 U.S.C. §403 and 404. We do not disclose your personal information to anyone, except in accordance with the Privacy Act. Authorized disclosures include limited circumstances such as the following ... to mailers, if already in possession of your name and old mailing address, as an address correction service. Information will also be provided to licensed service providers of the USPS to perform mailing list correction service of lists containing your name and old address. A list of these licensed service providers can be obtained at the following URL: http://ribbs.usps.gov/ncoalink /documents/tech_guides/CERTIFIED_LICENSEES"
They imply they only provide the new address but saying "the information you supply" leaves it open to for them to provide your phone number along with your new address.
