Another example:

# atomic install atomic-test 'asdf&jkl'
docker run --rm=true --net=host -v /:/host -e NAME=atomic-test -e IMAGE=atomic-test -e HOST=/host atomic-test /bin/install.sh 'asdf&jkl'
Parameters:
  'asdf&jkl'

vs. the correct

# atomic install atomic-test 'asdf&jkl'
docker run --rm=true --net=host -v /:/host -e NAME=atomic-test -e IMAGE=atomic-test -e HOST=/host atomic-test /bin/install.sh 'asdf&jkl'
Parameters:
  asdf&jkl

Also, there is regression with the non-US-ASCII character handling, compared to atomic 1.8 (see bug 1307034 command 4):

# atomic install atomic-test ježek
'ascii' codec can't decode byte 0xc5 in position 3: ordinal not in range(128)

Even just plain

LABEL INSTALL 'bash -c "echo arg1 arg2"'

seems to be broken now:

# atomic install atomic-test
bash -c "echo arg1 arg2"
arg1: -c: line 0: unexpected EOF while looking for matching `"'
arg1: -c: line 1: syntax error: unexpected end of file

vs. the original (and correct)

# atomic install atomic-test
bash -c echo arg1 arg2
arg1 arg2

with atomic-1.6-6.gitca1e384.el7.x86_64.

Jan could you check out

https://github.com/projectatomic/atomic/pull/336

(In reply to Daniel Walsh from comment #6)
> Jan could you check out
> 
> https://github.com/projectatomic/atomic/pull/336

Yes, that patch fixes cases from comment 0, comment 1, and comment 5.

The ascii codec issues from comment 2 is still present.

@Jan,

Would it be possible for you to pull my atomic_ascii branch and see if it passes comment #2 now?  Might also be worth checking that the other use cases are also valid.

https://github.com/baude/atomic/tree/atomic_ascii

Applying just the 7e34f5d7cd6b2a57d855d1faba22c041e02182bc on top of atomic-1.9-4.gitff44c6a.el7.x86_64 and https://github.com/projectatomic/atomic/pull/336 does not resolve the

'ascii' codec can't decode byte 0xc5 in position 3: ordinal not in range(128)

issue.

I also wonder why you specifically target UTF-8 there. While it likely is the encoding that the majority will use, atomic should not really care about the encoding at all -- just pass verbatim whatever parameters there are on the command line.

We should add this to the test suite to make sure we handle this situation.

Jan what code are you referring to exactly for "utf-8"  Could you submit a patch.

I was commenting on https://github.com/baude/atomic/commit/7e34f5d7cd6b2a57d855d1faba22c041e02182bc#diff-555a8731c137f41d8ec2a5b76216bdecR679

Jan please review

https://github.com/projectatomic/atomic/pull/358

Jan so you are saying there is no need for

 -        return " ".join(args)
+        return " ".join([x.decode('utf-8') for x in args])


Is this code alright?


 +    # break command into list
+    try:
         cmd = shlex.split(cmd)
+    except UnicodeEncodeError:
+        # The command contains a non-ascii character
+        cmd = shlex.split(" ".join([x.encode('utf-8') for x in cmd.split()]))

(In reply to Daniel Walsh from comment #14)
> Jan so you are saying there is no need for
> 
>  -        return " ".join(args)
> +        return " ".join([x.decode('utf-8') for x in args])
> 
> 
> Is this code alright?

I really don't know, I'm not expert on encodings in python.

But if you do

echo malá | iconv -f utf8 -t iso88591 | xargs echo

you will get ISO-8859-1 character (single byte) which is not UTF-8 (try piping to od -c). I'm not sure what the situation with non-UTF-8 is in Asian parts of the world.

 atomic install atomic-test ježek 'foo bar'docker run --rm=true --net=host -v /:/host -e NAME=atomic-test -e IMAGE=atomic-test -e HOST=/host atomic-test /bin/install.sh 'ježek' 'foo bar'
ježek
foo bar

So this is what we currently have?  Jan what should the output be?

The output looks good.

Thank you.

Fixed in atomic-1.10

I confirm that cases from comment 0, comment 1, comment 2, and comment 5 now give expected results with

python-docker-py-1.7.2-1.el7.noarch
atomic-1.10.3-2.el7.x86_64

Moving the bug to VERIFIED status per Comment 19 and actually testing on atomic-1.10.3-2 and atomic-1.10.5-3 w/ python-docker-py-1.7.2-1.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1273