Sending #cr to a String instantiation stream given by #streamContents: unexpectedly puts an #lf rather than #cr Character as demonstrated by the example in the Dockerfile given below:
$ image=$(docker build -q .) && docker run $image
[…]
topaz 1> printit
(String streamContents: [ :stream | stream nextPut: Character cr; cr ])
asArray collect: [ :character | character codePoint ]
%
a Array
#1 13
#2 10
topaz 1> printit
{ Character cr. Character lf }
collect: [ :character | character codePoint ]
%
a Array
#1 13
#2 10
[…]
I’m mostly adding this issue for reference; the behavior of #cr on Stream putting an #lf Character does seem to be intentional as some subclasses, such as AppendStream and WriteStreamPortable, have an override for #cr that puts a #cr Character instead. A question though is whether such an override shouldn’t also apply to the streams that #streamContents: uses.
Dockerfile:
FROM ubuntu:20.04
COPY <<"EOF" /home/gsuser/example
login
printit
(String streamContents: [ :stream | stream nextPut: Character cr; cr ])
asArray collect: [ :character | character codePoint ]
%
printit
{ Character cr. Character lf }
collect: [ :character | character codePoint ]
%
exit
EOF
COPY <<"EOF" /home/gsuser/runExample
cd ~/GsDevKit_home &&
. bin/defHOME_PATH.env &&
startStone devKit_363 &&
sed $'s/^\t//' <~/example | \
startTopaz devKit_363 -l
EOF
COPY <<"EOF" /home/gsuser/installGS
git -C ~ clone --depth 1 https://github.com/GsDevKit/GsDevKit_home.git &&
cd ~/GsDevKit_home &&
. bin/defHOME_PATH.env &&
installServerClient &&
createStone devKit_363 3.6.3 &&
createClient tode1
EOF
COPY <<"EOF" /root/setup
apt-get update &&
DEBIAN_FRONTEND=noninteractive apt-get --assume-yes install \
sudo tzdata lsb-release git &&
apt-get clean &&
useradd gsuser &&
chown --recursive gsuser ~gsuser &&
echo 'gsuser ALL=(ALL) NOPASSWD:ALL' >/etc/sudoers.d/gsuser
EOF
RUN bash /root/setup
RUN sudo --user gsuser bash /home/gsuser/installGS
CMD sudo --user gsuser bash /home/gsuser/runExample
Sending
#crto a String instantiation stream given by#streamContents:unexpectedly puts an#lfrather than#crCharacter as demonstrated by the example in the Dockerfile given below:I’m mostly adding this issue for reference; the behavior of
#cron Stream putting an#lfCharacter does seem to be intentional as some subclasses, such as AppendStream and WriteStreamPortable, have an override for#crthat puts a#crCharacter instead. A question though is whether such an override shouldn’t also apply to the streams that#streamContents:uses.Dockerfile: