python

irb

php --version

tclsh

For PHP, it also shows up in Apache's server string:

Apache/2.4.46 (Unix) PHP/7.3.24-(to be removed in future macOS) mod_perl/2.0.9 Perl/v5.30.2 on hostname

Personally, I've been hoping they'd do this for a while since it's annoying having two versions of each interpreter installed (the system one that can't be updated and the one I installed myself via Mac Ports). Anyone who uses these languages much probably already has a package manager installed. I think they should leave Perl, though, since it's as much as Unix system utility like awk or sed as a programming language.

  % /usr/bin/python

  WARNING: Python 2.7 is not recommended.
  This version is included in macOS for compatibility with legacy software.
  Future versions of macOS will not include Python 2.7.
  Instead, it is recommended that you transition to using 'python3' from within Terminal.

  Python 2.7.16 (default, Mar 25 2021, 03:11:28)
  [GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

  % /usr/bin/python3
  Python 3.8.2 (default, Dec 21 2020, 15:06:04)
  [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>>

   % /usr/bin/python3
  xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.

I don't like how Apple handles this. If you have the developer tools installed, it's not especially obvious what is part of those tools and what is actually bundled with the OS. And so it's not surprising that some scripts I've come across will silently break in semi-odd ways without the dev tools.

Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?

There's long been problems with this on UNIX systems. For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. / is different and has/had other constrains and reasons behind usage).

OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. At the same time, it's user installed, so /usr/local seems valid. Both make the other used of those locations more complicated to reason about.

> Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?

Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not).

The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. If users update it system wide, they can break OS assumptions.

/opt

> The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition) and the Intel Binary Compatibility Standard v. 2 (iBCS2) provides for an /opt structure very similar to the one defined here.

* https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/opt.htm...

MacPorts uses /opt/local for example.

The LFS spec you linked to is actually ancient at version 0.65, the latest is 3.0 and available here[1]. It's a bit "do what you want", but it really expects the "local" part of /opt/local that MacPorts uses to be some sort of identifier for MacPorts.

That said, it's the Linux Filesystem Hierarchy, so it only applies to Apple stuff inasmuch as it's common practices for UNIXes in general. And it's not like the major Linux distros follow it fully either. They're happy to break from it where it preserves some historical layout their OS has had that they think is easier for their users/admins.

1: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

Previously, lldb's extension language was python2. This changed a release or two of Xcode ago. At that time, to use lldb scripts with that new release of Xcode you either had to run on Catalina (which added python3 to the existing python2) or install your own python3 and point lldb at that. This actually was what pushed me into moving to Catalina on my development system, because the Unicode handling would be much easier in python3.

As I understand it, Monterey and the Xcode that is released for it move the necessary python3 installation from the operating system itself to Xcode. I'm fine with that.

(I would not be fine with Apple telling me I have to go waste my time figuring out how to install a suitable python myself, when I never had to before. And indeed, many of their own developers may be like me and know a little Python but are in trepidation of the env thing.)

The way it was before meant that if they wanted to update python they had to release a new version of the operating system. This is clearly an imposition on the vast bulk of macOS users, who are not developers.

So there needs to be a shell, and that's zsh now.

Apple switched to zsh because they're allergic to later GNU licenses and the version of bash they were shipping was absurdly out of date.

Possible approaches that would be less confusing than what we have today:

1. Ship Python 3 with macOS.

2. Ship all of the command-line developer tools with macOS, including clang et al.

3. Bring back the Snow-Leopard-era /Developer folder, and put developer tools there.

4. Put developer tools in /usr/developer, or /usr/local/developer, or /usr/local/Apple, to balance both UNIXness and clarity.

5. Don't ship Python at all. The Python foundation already distributes a .pkg installer for Mac. If xCode needs Python, follow your own Human Interface Guidelines and put it in the Application bundle.

All of these approaches have downsides, but I still think they'd be clear improvements over the current situation. Which is to say, I want Apple to figure this out!

At the time the GPLv3 was written, the GPLv3 was deliberately crafted to put commercial companies into a conflict situation.

(A) Give up selling audio with DRM (DRM did go away) (A) Give up selling video with DRM (A) Give up using HDMI as an output port (A) Give up using digital signatures to secure the integrity of software

-OR-

(B) Give up using GPL v3 software, GCC, Bash

Pretty sure most customers actually want many of the things in (A) and a minority actually care about (B). The items in (B) can be post-installed by those that really want it. Sure those in (B) have a loud voice, but, HN, are they really representative (democratically a majority)?

How would you make the choice between (A) or (B)?

I would bet that if a subeoena for FSF/GNU email was issued there would be a lot of messages related to manipulation and coercion for licensing and re-licensing. The sort of stuff, when associated with companies turns into scandal, lawsuits and monopoly investigations. (GCC almost got to be what could be considered a monopoly compiler)

I do believe that open software has a place and is a really good choice. My opinion is that the GPLv3 is completely toxic, spawned from negativity and is ultimately anti-open source. I will never release any software under the GPLv3.

Does GPLv3 really prevent an OS from doing those things? I think it would just prevent it in the same executable as GPLv3 software?

I don’t actually understand Apple’s “allergy”. On the iPhone I’m sure they object to the Tivoization clause (which coincidentally is why I like to use GPLv3), but I’m pretty darn sure macOS doesn’t fall afoul of anything...

Python 2.7 might be there because old software is there for compatibility reasons for software possibly for mathematical software that never really gets updated. Removing it in future versions makes sense because of the fact that if you haven't updated it won't work on ARM Macs.

The best way to make someone upgrade is to deprecate and then remove access. At minimum the worst case scenario is they roll their own and install Python 2.7.

How exactly is the above supposed to work when /usr/bin/python doesn't exist. If Apple chose to break the #! contract by doing something else, how would you feel about that?

This answer implies all "python" binaries across all operating systems and distributions for all time, are backwards and forwards compatible, no work needed. Guaranteed 100% equivalent.

What about Python2 v.s. Python3?

This isn't true and cannot ever be. This happens for other scripting and interpreted languages.

This approach means that the burden of choice and setup is transferred 100% to the person running the script. If you have 2 scripts that require different dependencies, then you will encounter this problem. I think it is this that encourages folks to include hard coded paths to enumerate explicit dependencies.

Lots of the "package" managers for these scripting languages also don't deal with this very well. They advocate a "do it my way" or "do it yourself". Different languages do it different ways.

Ultimately, the person wanting to run the script, just wants to make it run -- they will follow the instructions to make it work and along the way will make "global" changes -- which will impact what will happen for any other script in the future. This will likely be diverged from anyone else who has a "base install".

The above is mostly about my observations with using Ruby, not Python. However, few attempts in using pre-packaged complex python "recipes" has always resulted in similar conflicts.

Practically speaking, how does using env versus the absolute path make this any better or worse? You as the script author don't know what version of Python/Ruby/Bash/etc lives in /usr/bin. Maybe you could do some kind of automagic detection based on the user's OS, but any such assumptions are likely to go stale over time.

All env does is give users a choice about where to put their binaries. The versioning situation is a real problem, but I don't think using env makes it better or worse.

there is a TON more you can do with powershell than you can with bash. Plus object pipelines are superior to text pipelines

You can also install Powershell on Linux. So I would say Powershell is the Powershell of Linux

I really have no issue with Apple trimming down the surface of the OS to a minimum.

I don't know if any "native" apps have leveraged them, though. That would be the real risk of disruption.

Also, as someone who never uses PHP, I'd really rather not have it on my machine. Scripting languages are a pretty big attack surface, even if it's just to pivot after initial compromise. I'd rather not have one there that's not being used.

It is weird to me the number of times 90's Linux Distros used Perl for things that are easy in awk, awk for things that are easy with cut, and other commands for things that are easy with POSIX shell baked-in facilities. I guess I'm just a shell snob.

So because you can't trust cut to do what you want, you'll probably reach for something like awk '{print $3}' instead.

Most of the time the script doesn't get more complicated and it's fine with cut/sed/wc etc, but at some point it tips the balance and I grumble to myself.

Even those tools suffer from Apple's lack of fucks given. I often have to replace included system commands with the homebrew equivalent because Apple's is missing some common functionality.

I wish Apple would just adopt homebrew as a firstparty package manager.

Before someone shares some bizarre workaround: no thanks.

It also broke so I uninstalled it. When I need to I go straight to their formulas and install by hand, as a non-admin user.

I think it's a difference in philosophy? Brew does a "good enough" job for the most common use case, supplementing Apple's janky *nix environment with commonly-needed tools, without a built-in package manager. It doesn't try to do complex simultaneous versions... in my (admittedly limited) experience, if you need to do that, you either do that in something like a project-based setup (npm/composer) or in a VM/container with its own packages.

In your situation, when you have multiple pythons running in the same environment, how does anyone given script know which one to call? What's a better way of doing this?

From the horse's mouth

You can also install it on Linux if you wish.

• https://github.com/Homebrew/brew/issues/10127#issuecomment-8...

• https://github.com/Homebrew/brew/issues/11275

Usually it's one or the other.

Integration with their other hardware devices is the more important moat right now, as is hardware.

I’ve always wanted to use Nix and have tried to get started a few times. It has always ended up seeming more trouble than it’s worth.

* Nix doesn't have support for GUI apps like homebrew cask does - which meant I couldn't drop homebrew anyway. * The nix ecosystem forums suggest using nix-shell for managing packages for other languages, eg. python, java - but it's been really difficult to convince team members to use nix instead of pyenv, conda, gradle etc

Nowadays macOS needs something like Homebrew to fill the gaps. It's still slightly better than Windows + WSL, but Microsoft is catching up, while Apple seems to think that iPadOS is the future.

There's a whole lot more to Unix and open source than GNU. macOS has current versions of many open source tools, such as zsh, awk, sqlite, tar, git, and xz.

If one is being pedantic, GNU is not even "open source" but rather is "free software," and macOS certainly is not free software.

On Linux, sure, but not on other Unix OSes (like *BSD)

I'm not saying it's an easy problem to solve. Just that Apple aren't dropping support out of respect to their customers. They're doing it because it's cheaper.

Apple seems to be really good at maintaining their profit margin.

Here, they not only realized it had become popular, but GNU licensing gave them an excuse to switch the default without much thrashing about.

The fact that I can `chsh -s /usr/local/bin/zsh` and macOS doesn't freak out is quite nice.

https://www.opengroup.org/openbrand/register/brand3668.htm

This is very subjective. I, for one, much prefer kde plasma. And there's a substantial breed of developers who would prefer a tiling window manager with good keyboard navigation, such as i3.

https://www.opengroup.org/openbrand/register/brand3668.htm

Windows Subsystem for Linus sure has been a game changer!

And while you can still find an traditional unix(tm) box here and there in the dusty forgotten corners of enterprise serverooms(i am personally responsible for maintaining a few hpux boxen), unix(tm) certification haven't really mattered since Linux became serious business which happened around the same time OSX was launched.

What used to matter was that you could run the same CLI tooling in an macos desktop as on an Linux server but i don't think this is an use case apple see's as particularly important for the future success of Apple.

It’s not as if they want their CLI interaction to be 1-for-1 with Linux, but relatively close seems to still be a priority.

Precovid, on any conference I went to, professional or academic, the amount of Apple laptops was insane. I'm sure they're running things locally or on Linux servers, but the fact that they work pretty well between them is important.

Actually, it would cost them a lot, due to the GPL. Sure, they could try and pull a Google re: Java/Oracle feud, but I doubt they will and for good reason.

They aren't for you. Move on.

The Google bit is particularly goofy. No, "Google" doesn't even appear on the charts (you know -- the charts which Apple usually is within the top 2, often leading). Chromebooks do, sold by a wide variety of sellers, as a schoolhouse special. Their great for what they do.

IT's an trip the classic macos took before it and i think there is an signficance in apple returning to the MAcOS branding thats subly hinting that the days when OSX was an relatively open unix is ending.

But it might help Apple to win government contracts.

% perl -de1

WARNING: This version of perl is included in macOS for compatibility with legacy software. In future versions of macOS the perl runtime will not be available by default, and may require you to install an additional package.

However, how come things break when Perl is upgraded? From what I've heard, Perl should be extremely backwards compatible. What am I missing?

https://perldoc.perl.org/perl#History

Those aren't an "incompatible changes seection".

perldelta covers bugfixes, feature additions etc.

   foreach entry in "https://perldoc.perl.org/perl#History" do
      open entry on browser
      search for "Incompatible Changes" section
      read section contents

Hint, use LWP.

Dude, there is literally a link with references.

Post-upgrade either various modules weren't found (because they were installed in a versioned path), or they didn't compile because the XS components had been compiled against the prior version of Perl.

I will often use the system perl to bootstrap https://p3rl.org/Perl::Build which makes building -one- perl for local use easier than perlbrew/etc. - and then https://p3rl.org/App::plx for managing per project environments if I need that

The way it is written, it sounds like they are trying to hide the fact that said "legacy software" is part of the (new) system itself. Otherwise they wouldn't need to include it in the base install.

> Python, Ruby, and Perl

The order they use for the languages hides the fact that, at least for Catalina, Perl is by far the most used scripting language by core elements of macOS, even more than the shell. Check it by yourselves:

    file -b /{usr/,}{s,}bin/* |cut -d\  -f1,2|sort|uniq -c|sort -n|tail

     13 setuid Mach-O
     23 a /usr/sbin/dtrace
     50 a /usr/bin/perl5.28
     53 a /usr/bin/perl5.18
     81 POSIX shell
    116 Perl script
    954 Mach-O 64-bit

And of course compile their scripts into executables or something.

It "lowers the friction of curiosity".

(And, it allowed our shadow IT custom request system and automation package to be built in 2014. I hope RHEL never takes this away).

I recently wrote a short Ruby program to help my not-computer-literate-at-all mother automate a task that would've taken hours and hours to do manually. She's barely comfortable using GUI programs, but because Ruby was already installed and I was able to give her clear directions she was able to run the program in Terminal.app without much trouble. It would've been frustrating as hell to remotely get her set up with homebrew (or whatever the new hotness is in package managers nowawadays), install the right version of Ruby, fix any $PATH shenanigans, etc.

(There was still some trickiness because her included version of Ruby was super old and couldn't install gems because it used an old version of SSL/TLS, but we were able to figure out a workaround)

Or default python2 breaking stuff that assume you have a recent install