PostInstallScript and friends adds #!/bin/sh #42

New Issue

claunia · 2026-01-29T16:27:55Z

claunia commented

2026-01-29 16:27:55 +00:00

Originally created by @TheAngryByrd on GitHub (Dec 6, 2018).

Currently the PostInstallScript (and others) adds #!/bin/sh to the script.
63b290277b/Packaging.Targets/Deb/DebPackageCreator.cs (L176)

The way I've been using this is to have MSBuild read in a file from disk that I've specified as the postinstall script. I've already added my shebang to the file, but when I go to deploy it has double them now. I think this should be up the user to add their shebang.

Originally created by @TheAngryByrd on GitHub (Dec 6, 2018). Currently the PostInstallScript (and others) adds `#!/bin/sh` to the script. https://github.com/qmfrederik/dotnet-packaging/blob/63b290277b4c8b7d3f09f696c2307740f0a12e52/Packaging.Targets/Deb/DebPackageCreator.cs#L176 The way I've been using this is to have MSBuild read in a file from disk that I've specified as the postinstall script. I've already added my shebang to the file, but when I go to deploy it has double them now. I think this should be up the user to add their shebang.

claunia commented

2026-01-29 16:27:56 +00:00

@qmfrederik commented on GitHub (Dec 6, 2018):

The reason #!/bin/sh get added is that other options (such as CreateUser or InstallService) dynamically construct a script, and we add the shebang at the very end to make the script valid.

Another way to handle this may be to store the user script "as is" in the package, and invoke it from the PreInstallScript.

@qmfrederik commented on GitHub (Dec 6, 2018): The reason `#!/bin/sh` get added is that other options (such as `CreateUser` or `InstallService`) dynamically construct a script, and we add the shebang at the very end to make the script valid. Another way to handle this may be to store the user script "as is" in the package, and invoke it from the PreInstallScript.

claunia commented

2026-01-29 16:27:57 +00:00

@TheAngryByrd commented on GitHub (Dec 6, 2018):

Or would it make sense to have a separate implementation for "inline" scripts and file paths?

@TheAngryByrd commented on GitHub (Dec 6, 2018): Or would it make sense to have a separate implementation for "inline" scripts and file paths?

claunia commented

2026-01-29 16:27:58 +00:00

@qmfrederik commented on GitHub (Dec 17, 2018):

That may work as well. Would you like for that to override any "auto-generated" script (like for CreateUser or InstallService)?

@qmfrederik commented on GitHub (Dec 17, 2018): That may work as well. Would you like for that to override any "auto-generated" script (like for `CreateUser` or `InstallService`)?

claunia commented

2026-01-29 16:27:59 +00:00

@TheAngryByrd commented on GitHub (Dec 17, 2018):

Yeah, if I'm providing my own scripts, I should bear the burden of setting up users/services correctly.

@TheAngryByrd commented on GitHub (Dec 17, 2018): Yeah, if I'm providing my own scripts, I should bear the burden of setting up users/services correctly.

claunia referenced this issue

2026-01-29 16:31:08 +00:00

[PR #42] [MERGED] Allow users to override the Linux file mode of files #192

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dotnet-packaging#42