Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

sudo make install

bvnf.space

Post reply on HN
Print view View original

31–38 of 38 posts

Re: sudo make install

#31

Post by pxc »

psyclobe wrote: post #28
pxc wrote: post #26

Earlier quoted context omitted.

PowerShell has platform-specific modules and ships by default with a ton of compatibility-breaking aliases. It doesn't really solve this problem

Sure it does, all the standard calls are universal, hell I wrote a _universal_ directory monitoring shell script. Try and do that with bash on windows/linux/osx.

If you're going to use PowerShell like a shell (i.e., to call external programs), you still have to worry about distributing them or variations between what's preinstalled.

If you're only going to use PowerShell functions and not external programs anyway, then PowerShell is more in competition with languages like Python, Perl, Ruby, etc., than it is with Bash.

PowerShell also falls down when it comes to the other distinguishing feature of a shell, which is that you gradually learn your scripting language just by using your computer, because PowerShell just falls flat as a daily login shell. This is mainly because it's unbelievably dog slow for a shell and lacks basic functionality like job control, but arguably also because of smaller things like its verbosity, extremely complicated profile sourcing behavior, etc.

PowerShell is still sometimes a good choice for cross-platform scripting, but I wouldn't say that's because of its compatibility.

Re: sudo make install

#32

Post by chriswarbo »

noirscape wrote: post #27
chriswarbo wrote: post #11

Earlier quoted context omitted.

Indeed. Also, scripts (especially Dockerfiles) which run `apt-get install foo bar baz`; usually mixed in with a bunch of other commands, and file copying/editing. That's literally what package formats like .deb, .rpm, etc. are for! For example: - Write your dependencies in a `my-package/DEBIAN/control` file - If you want any extra files, put those in your `my-package/` folder too (e.g. `my-package/etc/some_config_fil…

The main issue when it comes to using Debian or most conventional package managers (nix really deserves its own mention there) is that you also pretty much distro lock your software, which may not be always beneficial. Another problem comes now in the form of distribution; packaging is one thing, distributing is another. Debian isn't too bad about this but depending on your choice of packager[0], you could suddenly n…

I agree with most of what you're saying, although we're describing slightly different use cases.

For example, using a .deb file is just as "distro locked" as the sort of "apt-get scripting" I was complaining about. It's pretty much a Pareto improvement to change a Dockerfile from `RUN apt-get install ...` to `RUN apt install ./my-package.deb` (we can construct the .deb wherever we like; outside the container, inside the container, in a separate container, etc.)

As for Docker being "easy"... I suppose that's subjective. Personally, it's given me nothing but pain; from trying to get the damn thing installed, to trying to understand it (lots of documentation turns out to be obsolete, and lots more assumes you're already familiar with its bizarro-world of not-invented-here concoctions).

I gave up trying to understand Docker itself. I learned much more by following the OCI specs, and building container images directly using `tar` and `sha256`. AWS ECS seems to run them just fine :)

Re: sudo make install

#33

Post by 0xbadcafebee »

phoebos wrote: post #19
0xbadcafebee wrote: post #12

> In my opinion, the best solution that POSIX.1-202x should use is to require make to set the PWD macro itself. The whole SCCS stuff in POSIX already requires make to think about PWD, so I don't see why this shouldn't happen It should't happen because make isn't the problem, it's sudo not setting PWD to what you expect by default. This isn't a make bug, it's a sudo bug. Author even explicitly says this. They just pre…

I would say it is a make bug in that POSIX make has no good way to get PWD. Not necessarily a bug even, but an annoyance.

> POSIX make has no good way to get PWD

It can.... get it from the environment.... like every application run by every operating system does. PWD is only ever set by a shell. It exports it as an environment variable. Programs can read environment variables passed to them.

Re: sudo make install

#34

Post by hulitu »

czx4f4bd wrote: post #21
dspillett wrote: post #9

Earlier quoted context omitted.

No, correct. But it is a good example of something that you might expect to be more standard than it is between platforms, because of its age and relative ubiquity, where the differences get highlighted when trying to create (not just with make but other tools too) a consistent build process for a project.

Yeah, variance between different system utilities is one of the biggest underrated perils of shell scripting. For a long time, I worked on a team that mostly used Macs to administer Linux servers, which led to some confusing issues when people tested certain commands locally and then tried to use them on a server. It would be nice if shellcheck had checks to detect common BSD/GNU incompatibilities and warn about them…

I think that if one aims for compatibility , then it shall use POSIX.

Re: sudo make install

#35

Post by phoebos »

0xbadcafebee wrote: post #33
phoebos wrote: post #19

Earlier quoted context omitted.

I would say it is a make bug in that POSIX make has no good way to get PWD. Not necessarily a bug even, but an annoyance.

> POSIX make has no good way to get PWD It can.... get it from the environment.... like every application run by every operating system does. PWD is only ever set by a shell. It exports it as an environment variable. Programs can read environment variables passed to them.

As you noted, I said that the problems stems from sudo not setting PWD, hence `sudo make` doesn't inherit PWD. I'm not calling that a bug in sudo, but it was a bug in the specific makefile which assumed PWD to be set always.

A good solution to the problem is for make to set the PWD macro. BSD make already does this.

> It can get if from the environment like every application does

Well no, applications either read an environment variable or use getcwd(2).

Re: sudo make install

#36

Post by DougMerritt »

pjmlp wrote: post #5
JamesonNetworks wrote: post #3

I’ve been working on Makefiles lately and its funny how many compatibility issues there are. I was doing Sed substitutions and found I needed to change the -i flag to make it work between Mac and Linux. I was really hoping for ultimate portability but ended up learning lots of hacks that lead to portability

GNU and POSIX differences, https://pubs.opengroup.org/onlinepubs/9699919799/ https://pubs.opengroup.org/onlinepubs/9699919799/

The second link is the same as the first; presumably you meant to post a different second link?

Re: sudo make install

#37

Post by MaxBarraclough »

sacnoradhq wrote: post #7

sudo make install is failure to use package management and an acceptance of unmanaged and increase system entropy. Tools like checkinstall are the way to go, at a minimum.

I've used a tool called porg. [0] Hadn't heard of checkinstall but it seems similar but with integration into the distro's package manager.

[0] https://porg.sourceforge.net/

Re: sudo make install

#38

Post by SAI_Peregrinus »

bdhcuidbebe wrote: post #4
JamesonNetworks wrote: post #3

I’ve been working on Makefiles lately and its funny how many compatibility issues there are. I was doing Sed substitutions and found I needed to change the -i flag to make it work between Mac and Linux. I was really hoping for ultimate portability but ended up learning lots of hacks that lead to portability

Differences in GNU/BSD sed is hardly a bug in Make.

But it is a bug in your Makefile to assume a particular version of a tool (or path to a tool, etc) without first checking (or otherwise forcing the correct thing to be used).

For forcing the existence of tools, you can start your Makefile by setting up $PATH with the dependencies your script has (everything not guaranteed by POSIX, for example). E.g. with Nix

`export PATH := $(shell nix-shell -p DEPENDENCY1 DEPENDENCY2 --run 'echo $$PATH')`

Will cause `make` to include DEPENDENCY1 and DEPENDENCY2 from the Nix store in $PATH for the rest of the Makefile. You can get more complex and pin particular versions where it matters.

Other cross-platform package management tools presumably have similar tricks that can be used, or you can bundle binaries for the tools you need. Then your build instructions only need to tell the user to have Make and the package management tool installed, and everything else can be set up in the Makefile.

Of course this is a PITA.

Post reply on HN