question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Error due to path separator inconsistency on windows

See original GitHub issue

Expected behaviour

sbt stage executed on windows should generate a consistent dockerfile, in terms of paths description.

Actual behaviour

Some paths in the output Dockerfile mix / and \, resulting in an error when building the image.

Information

  • sbt-native-packager: 1.7.0
  • sbt version: 1.3.8
  • build system: Windows
  • Package built: docker

Reproduction

I’m using a custom start script, called “startDocker.sh” and put in <project home>/src/universal/bin

When adding a custom entrypoint in sbt

dockerEntrypoint := Seq("/opt/docker/bin/startDocker.sh")

the result on macos / linux contains (as expected):

RUN ["chmod", "u+x,g+x", "/1/opt/docker/bin/startDocker.sh"]

but on windows, the same line is

RUN ["chmod", "u+x,g+x", "/1/opt/docker/bin\startDocker.sh"]

I would not bother too much about this if the consequence wasn’t docker to return the following error when running docker build (or docker:publish)

Step 12/25 : RUN ["chmod", "u+x,g+x", "/opt/docker/bin\startDocker.sh"]
 ---> Running in f6b9fec09930
/bin/sh: 1: [chmod,: not found
The command '/bin/sh -c ["chmod", "u+x,g+x", "/opt/docker/bin\startDocker.sh"]' returned a non-zero code: 127

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Reactions:1
  • Comments:11 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
JessePeltoncommented, Apr 27, 2020

I’ve been wrestling for hours with a problem that may be related, though it has nothing whatever to do with Docker. I want to control the collection of files archived by universal:packageZipTarball on a Windows system. Specifically, I want to archive everything in mappings except the contents of a subdirectory tree. On Windows, the following code doesn’t quite work to generate the list of files to be archived.

lazy val zipping = {
  mappings --= (file("excluded/directory") ** "*")
    .get
    .map(file => baseDirectory.value / file.getPath -> file.getPath)
}

Running show mappings in the sbt console makes it clear why: the path for each mapping in the subdirectory has a forward slash for its first directory separator, and any subsequent separators are backslashes: excluded/directory\and\subdirectories.

Consequently I have to employ the following string replacement hack to get the desired behavior.

lazy val zipping = {
  mappings --= (file("excluded/directory") ** "*")
    .get
    .map(file => baseDirectory.value / file.getPath -> file.getPath.replaceFirst("\\\\", "/"))
}

So, while it’s true that

Destination paths for mappings use system path separators

that’s not the whole problem for me, because system path separators aren’t used exclusively. If they were, my hack wouldn’t be required.

It might be better in the general case if the destination paths used / consistently. I could live with that; it’s easier to understand why replace('\\', '/') would be necessary than replaceFirst("\\\\", "/").

1reaction
nigredo-toricommented, Apr 15, 2020

I understood the issue that on the host system windows things get strange. Not that a docker image is based on windows, right? Docker confuses me so fast stuck_out_tongue_winking_eye

We actually have 3 environments here:

  1. Whatever is running SBT (I’ll call it the SBT host). In this case this is Windows.
  2. Whatever will build the Dockerfile (Docker host).
  3. Whatever the docker image has (image). In this case it’s probably some flavor of Linux

The issue here is that on the SBT host the generated mappings use Windows path separators (backslashes). However, the image (where the chown command is executed) expects the Dockerfile to contain *nix path separators (forward slashes). So we need to convert SBT host OS path separators to image OS path separators. We want to be able to configure SBT so that the Dockerfile commands use the path separators in the Dockerfile to what image expects. We have no good way of knowing what those are for the image we’re building, but defaulting to *nix separators seems reasonable. Note that the docker host OS is irrelevant here, though it has some corellation with the image OS.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Why does the cmd.exe shell on Windows fail with paths using ...
Another point of interest is that changing directories with 'cd' and using '/' used as a path separator with cmd.exe does work: C:\temp\tcbugs>mkdir ......
Read more >
Why Does Windows Really Use Backslash as Path Separator?
Microsoft reportedly wanted to use the forward slash as path separator, but IBM nixed the idea because it would have created an incompatibility...
Read more >
MySQL Bugs: #45549: UDF plugin_dir path separator ...
Got lib_mysqludf_xql.dll working, it was failing due to missing ... Would be good to have path inconsistency fixed and windows errors made ...
Read more >
Vim error: Unable to open swap file when using backslash as ...
Vim error: Unable to open swap file when using backslash as path separator in Windows shell · I don't know anything about cmder...
Read more >
The input path refers to a file but ends with a directory ...
To correct this error. Check the file path you supplied to ensure it is correct. Remove the extraneous character. See also.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found