If it's a one off, you just use something like "nix shell" to add it to your path for running the script.
For non one-off sorts of things, you would substitute in the nix expression "${gnugrep}/bin/grep" the "${gnugrep}" will expand to "/nix/store/grep-hash" and also make a dependency on the gnugrep package, so that the grep install won't get garbage-collected as long as your package is still around.
Here's an example[1] from a package expression for e-mail client I use, which will shell out to base64 and file. Upstream relies on these two programs being in $PATH, but this replaces the string used for shelling out with the absolute path in the nix store.
For shell scripts, I'll just do something like this near the top:
GREP="${GNU_GREP:-$(command -v grep)}"
Then I use "$GREP" in the script itself, and develop with grep in my path, but it's trivial to prepend all of my dependencies when I bundle it up for nix.
[user@nixos:~]$ which grep
/run/current-system/sw/bin/grep
[user@nixos:~]$ ls -l /run/current-system/sw/bin/grep
lrwxrwxrwx 1 root root 65 Jan 1 1970 /run/current-system/sw/bin/grep -> /nix/store/737jwbhw8ji13x9s88z3wpp8pxaqla92-gnugrep-3.12/bin/grep
Basically, it is still in your environment, so I don't see how he can claim that this problem doesn't exist in Nix, unless you use flakes like a proper Nix afficionado.
Yes, the original comment that this problem doesn't exist in Nix is wrong for a typical user environment.
It does contain the issue a bit though:
I'm running isync in a systemd service, yet the program "mbsync" is not in my path. I have several services installed, yet their programs aren't in my path. My e-mail client shells out to "file" for mime-type verification, yet "file" is not in my path.
Run "compgen -c |wc -l" to get a list of commands; its over 7000 on my Ubuntu system and right around 2000 on my NixOS system.
As an aside, the packages that put the most executables in my path are probably going to be in the path for most NixOS installs (231 just for coreutils+util-linux):
True enough, but in my experience it's not really much of a problem because if I'm not doing Nix, then I'm doing containers which are widely available.
What can be a problem is muscle memory, when you expect it to autocomplete one way and it doesn't because something you want now shares first two or three letters with something else in your path. That's where FIGNORE comes in.
>> No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs
> You say this with zero data.
Wouldn't the null hypothesis be that the same program behaves differently on different CPUs?
Is "different people require different amounts of time to run 100m" a statement that requires data?
I remember $CURRENT_YEAR taking off around 2016 where it was used in the innocent days of the culture wars alongside terms like "dongle" and "shitlord".
I find it concerning that kilo can mean both 10^3 and 2^10 depending on context.
And that the context is not if you're speaking about computery stuff, but which program you use has almost certainly lead to avoidable bugs.
That latter part is only true since marketing people decided they knew better about computer related things than computer people.
It's also stupid because it's rare than anyone outside of programming even needs to care exactly how many bytes something else. At the scales that each of kilobyte, megabyte, gigabyte, terabyte etc are used, the smaller values are pretty much insignificant details.
If you ask for a kilogram of rice, then you probably care more about that 1kg of rice is the same as the last 1kg of rice you got, you probably wouldn't even care how many grams that is. Similarly, if you order 1 ton of rice, you do care exactly how many grams it is, or do you just care that this 1 ton is the same as that 1 ton?
This whole stupidity started because hard disk manufacturers wanted to make their drives sound bigger than they actually were. At the time, everybody buying hard disks knew about this deception and just put up with it. We'd buy their 2GB drive and think to ourselves, "OK so we have 1.86 real GB". And that was the end of it.
Can you just imagine if manufacturers started advertising computers as having 34.3GB of RAM? Everybody would know it was nonsense and call it 32GB anyway.
Not as far as I can tell. There's power of 10 bits and power of 2 bytes. I've never seen the inverse of those in an actual real world scenario outside of storage manufacturers gaming the numbers but even then the context is once again perfectly clear.
The "which program you use" confusion was instigated by the idiots insisting that we should have metric kilobytes, megabytes and gigabytes (cheered on by crooked storage manufacturers).
Before all that nonsense, it was crystal clear: a megabyte in storage was unambiguously 1024 x 1024 bytes --- with the exception of crooked mass storage manufacturers.
There was some confusion, to be sure, but the partial success of attempt to redefine the prefixes to their power-of-ten meanings has caused more confusion.
nice idea, but "small composable programs" includes perl scripts? That's great if you're already using perl, a bit much to install if you're not.
There shouldn't be any burden of portability for the one writing small tools like these.
You're free to rewrite it, of course, but expecting someone to go out of their way to stay within the unix/posix/whatever environment seems a bit much given the context of an unpaid endeavor.
For meshed networks there is a secondary ID (with a name I do not know) that is used to distinguish between APs, since your device should only talk to at most one AP at a time.
It wouldn't be surprising if they used that for finding the location, but marketing sells it as SSID matching as the people they want to sell it to are most likely not experts in networking.
The ESSID (Extended Service Set Identifier) is the human-readable thing you see. There is an underlying BSSID (Basic Service Set Identifier) that includes the unique identifier for the AP (its MAC address) your mobile unit is associated with.
On Windows you can see this (from an elevated context and, in newer versions, with location services enabled) by running: "netsh wlan show interfaces"
So why not allow for enabling this behavior as a configuration option?
A big fat banner for most users (i.e. by default) and the few edge cases get the status bar entry after they asked for it.
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
/nix/store/grep-hash -flags files | /nix/store/head-hash
instead of: "grep -flags files | head"?
reply