/usr/bin/josm is broken (/usr/bin/josm: /usr/bin/bash: bad interpreter: No such file or directory)

[sebastic]

#22088 broke /usr/bin/josm on non-usrmerge systems:

$ /usr/bin/josm 
bash: /usr/bin/josm: /usr/bin/bash: bad interpreter: No such file or directory

The interpreter change in r18497 needs to be reverted, the following patch is included in the Debian package to do so:

Description: Fix bash path.
Author: Bas Couwenberg <sebastic@debian.org>
Bug: https://josm.openstreetmap.de/ticket/22088

--- a/native/linux/tested/usr/bin/josm
+++ b/native/linux/tested/usr/bin/josm
@@ -1,4 +1,4 @@
-#!/usr/bin/bash
+#!/bin/bash
 # Simple wrapper script used to start JOSM in Debian
 set -e

The same change needs to be applied for josm-latest:

--- a/native/linux/latest/usr/bin/josm-latest
+++ b/native/linux/latest/usr/bin/josm-latest
@@ -1,4 +1,4 @@
-#!/usr/bin/bash
+#!/bin/bash
 # Simple wrapper script used to start JOSM in Debian
 set -e
 

[taylor.smock]

I'll note a few things:

1. In #22157, skyper (a fairly long-time reporter/contributor) noted that /bin/bash and /usr/bin/bash were exhibiting different behaviors (see comment:13:ticket:22157)
2. I left #22088 open for a few weeks so that packagers could give feedback. I then merged the patch a bit earlier than I wanted to due to #22157, but that was two weeks ago. We have yet to receive reports from those running josm-latest from our repository (see wiki:/Download#Ubuntu -- this technically also works on Debian distributions)
3. I think you mean r18497 not r18500
4. Based off of #22157, I am disinclined to move back to /bin/bash. I am open to moving to /usr/bin/env bash.
5. From comment:16:ticket:22088, "I thought usrmerge was mandatory. See ​​https://wiki.debian.org/UsrMerge ." The followup in comment:17:ticket:22088 said "Only new installations use usrmerge by default, upgraded systems need to explicitly install the usrmerge package if they want to adopt Merged /usr." along with a comment about the dpkg maintainer being resistant to change.
6. Looking at popcon statistics for ​JOSM and ​usrmerge, it looks like 1 in 7 users might be affected. But then looking at the debian ​package page for JOSM, only bullseye-backports, bookworm, and sid have recent versions of JOSM available. From the usrmerge page, debootstrap has defaulted to usrmerge since 1.0.102. Which was in ​buster (2019-07-06). This removed the need for new installs to add usrmerge.

EDIT: FTR, buster is scheduled to go EOL in ​August.

[skyper]

I've just installed josm_0.0.svn18463+dfsg-1~bpo11+1_all.deb from bullseye-backports and it suffers the same bug (#22157) on my bullseyes system.

[sebastic]

Replying to taylor.smock:

1. In #22157, skyper (a fairly long-time reporter/contributor) noted that /bin/bash and /usr/bin/bash were exhibiting different behaviors (see comment:13:ticket:22157)

This suggests something specific to that system.

Ubuntu may have some AppArmor or other LSM affecting bash.

2. I left #22088 open for a few weeks so that packagers could give feedback. I then merged the patch a bit earlier than I wanted to due to #22157, but that was two weeks ago. We have yet to receive reports from those running josm-latest from our repository (see wiki:/Download#Ubuntu -- this technically also works on Debian distributions)

I was not CCed, hence not aware of the josm launcher changes until the new tested release was published with those changes.

3. I think you mean r18497 not r18500

Yes, OP corrected.

4. Based off of #22157, I am disinclined to move back to /bin/bash. I am open to moving to /usr/bin/env bash.

/bin/bash should work everywhere, on systems where it doesn't further investigation is needed, not a change to the shebang of josm.

5. From comment:16:ticket:22088, "I thought usrmerge was mandatory. See ​​https://wiki.debian.org/UsrMerge ." The followup in comment:17:ticket:22088 said "Only new installations use usrmerge by default, upgraded systems need to explicitly install the usrmerge package if they want to adopt Merged /usr." along with a comment about the dpkg maintainer being resistant to change.

The takeaway is that you shouldn't rely on systems having an /usr merge filesystem layout for the time being.

6. Looking at popcon statistics for ​JOSM and ​usrmerge, it looks like 1 in 7 users might be affected. But then looking at the debian ​package page for JOSM, only bullseye-backports, bookworm, and sid have recent versions of JOSM available. From the usrmerge page, debootstrap has defaulted to usrmerge since 1.0.102. Which was in ​buster (2019-07-06). This removed the need for new installs to add usrmerge.

All my Debian installs are quite old, some were initially installed with woody and dist-upgraded every since. Only new installs since buster have usrmerge by default, hence only a subset of Debian systems out in the wild. For people like me who dist-upgraded to bullseye usrmerge is opt-in.

[sebastic]

Replying to skyper:

I've just installed josm_0.0.svn18463+dfsg-1~bpo11+1_all.deb from bullseye-backports and it suffers the same bug (#22157) on my bullseyes system.

Which distribution was initially installed on that system? Was it a fresh install of bullseye, or did you dist-upgrade to bullseye from buster or earlier?

In other words, how can we reproduce your environment?

[skyper]

Replying to sebastic:

Which distribution was initially installed on that system? Was it a fresh install of bullseye, or did you dist-upgrade to bullseye from buster or earlier?

This is a fresh installation of bullseye. I had no issues on my old computer which was dist-upgraded several times.

[sebastic]

I cannot reproduce the issue on a bullseye system (LiveCD) with a merged /usr filesystem layout:

user@debian:~$ ls -l / | grep "\-> usr"
lrwxrwxrwx   1 root root    7 Mar 26 15:22 bin -> usr/bin
lrwxrwxrwx   1 root root    7 Mar 26 15:22 lib -> usr/lib
lrwxrwxrwx   1 root root    9 Mar 26 15:22 lib32 -> usr/lib32
lrwxrwxrwx   1 root root    9 Mar 26 15:22 lib64 -> usr/lib64
lrwxrwxrwx   1 root root   10 Mar 26 15:22 libx32 -> usr/libx32
lrwxrwxrwx   1 root root    8 Mar 26 15:22 sbin -> usr/sbin

user@debian:~$ ls -l /bin/bash /usr/bin/bash
-rwxr-xr-x 1 root root 1234376 Aug  4  2021 /bin/bash
-rwxr-xr-x 1 root root 1234376 Aug  4  2021 /usr/bin/bash

user@debian:~$ head -1 /usr/bin/josm
#!/bin/bash

user@debian:~$ /usr/bin/josm --version
Using /bin/java to execute josm.
JOSM/1.5 (18463 Debian en) Linux Debian GNU/Linux 11 (bullseye)

[skyper]

Replying to sebastic:

user@debian:~$ /usr/bin/josm --version
Using /bin/java to execute josm.
JOSM/1.5 (18463 Debian en) Linux Debian GNU/Linux 11 (bullseye)

"Using /bin/java to execute josm." does not look like it is working. Please add your status report, especially, the VM arguments are important.

user@localhost:~$ ls -l / | grep "\-> usr"
lrwxrwxrwx   1 root root     7 Feb 23  2021 bin -> usr/bin
lrwxrwxrwx   1 root root     7 Feb 23  2021 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Feb 23  2021 lib32 -> usr/lib32
lrwxrwxrwx   1 root root     9 Feb 23  2021 lib64 -> usr/lib64
lrwxrwxrwx   1 root root    10 Feb 23  2021 libx32 -> usr/libx32
lrwxrwxrwx   1 root root     8 Feb 23  2021 sbin -> usr/sbin

user@localhost:~$ ls -l /bin/bash /usr/bin/bash
-rwxr-xr-x 1 root root 1234376 Aug  4  2021 /bin/bash
-rwxr-xr-x 1 root root 1234376 Aug  4  2021 /usr/bin/bash

user@localhost:~$ /usr/bin/josm --version
Using /bin/java to execute josm.
JOSM/1.5 (18463 Debian en) Linux Debian GNU/Linux 11 (bullseye)

user@localhost:~$ /usr/bin/josm --status-report
Using /bin/java to execute josm.
Revision:18463
Is-Local-Build:false
Build-Date:1970-01-10 17:37:24
Debian-Release:0.0.svn18463+dfsg-1~bpo11+1
Build-Name:Debian

Identification: JOSM/1.5 (18463 Debian en) Linux Debian GNU/Linux 11 (bullseye)
Memory Usage: 190 MB / 2970 MB (177 MB allocated, but free)
Java version: 17.0.3+7-Debian-1deb11u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00) :0.1 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: GNOME
libcommons-compress-java: libcommons-compress-java:all-1.20-1
fonts-noto: fonts-noto:all-20201225-1
VM arguments: [-Djosm.restart=true, -Djava.net.useSystemProxies=true]
Program arguments: [--status-report]

user@localhost:~$ /usr/bin/josm-latest --status-report
Using /usr/lib/jvm/java-17-openjdk-amd64/bin/java to execute josm-latest.
Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2022-07-05 19:14:22 +0200 (Tue, 05 Jul 2022)
Revision:18511
Build-Date:2022-07-06 01:30:57
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (18511 en) Linux Debian GNU/Linux 11 (bullseye)
Memory Usage: 190 MB / 2970 MB (157 MB allocated, but free)
Java version: 17.0.3+7-Debian-1deb11u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00) :0.1 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Desktop environment: GNOME
libcommons-compress-java: libcommons-compress-java:all-1.20-1
fonts-noto: fonts-noto:all-20201225-1
VM arguments: [--module-path=/usr/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djosm.dir.name=JOSM-latest, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]
Program arguments: [--status-report]

[taylor.smock]

Replying to sebastic:

Replying to taylor.smock:

2. I left #22088 open for a few weeks so that packagers could give feedback. I then merged the patch a bit earlier than I wanted to due to #22157, but that was two weeks ago. We have yet to receive reports from those running josm-latest from our repository (see wiki:/Download#Ubuntu -- this technically also works on Debian distributions)

I was not CCed, hence not aware of the josm launcher changes until the new tested release was published with those changes.

I, unfortunately, do not have a list of people to CC for launcher changes. One of the other maintainers might have such a list.

4. Based off of #22157, I am disinclined to move back to /bin/bash. I am open to moving to /usr/bin/env bash.

/bin/bash should work everywhere, on systems where it doesn't further investigation is needed, not a change to the shebang of josm.

I'm probably just going to switch to /usr/bin/env bash, since it looks like that will probably work on the BSDs. I haven't tested the rest of the script on BSD, but it won't just error out immediately.

[taylor.smock]

In 18512/josm:

Fix #22193: /usr/bin/bash is not present on all Debian systems

This switches to /usr/bin/env bash.

[sebastic]

Replying to skyper:

"Using /bin/java to execute josm." does not look like it is working. Please add your status report, especially, the VM arguments are important.

It's working just fine:

user@debian:~$ ls -l /bin/java
lrwxrwxrwx 1 root root 22 Jul  7 14:39 /bin/java -> /etc/alternatives/java
user@debian:~$ ls -l /etc/alternatives/java
lrwxrwxrwx 1 root root 43 Jul  7 16:02 /etc/alternatives/java -> /usr/lib/jvm/java-17-openjdk-amd64/bin/java

With openjdk-11-jre (default-jre):

$ JAVACMD=/usr/lib/jvm/java-11-openjdk-amd64/bin/java /usr/bin/josm

Revision:18463
Is-Local-Build:false
Build-Date:1970-01-10 17:37:24
Debian-Release:0.0.svn18463+dfsg-1~bpo11+1
Build-Name:Debian

Identification: JOSM/1.5 (18463 Debian en) Linux Debian GNU/Linux 11 (bullseye)
Memory Usage: 171 MB / 984 MB (79 MB allocated, but free)
Java version: 11.0.14+9-post-Debian-1deb11u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1200 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1200
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Java package: openjdk-11-jre:amd64-11.0.14+9-1~deb11u1
Java ATK Wrapper package: libatk-wrapper-java:all-0.40.0-2~bpo11+1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
fonts-noto: fonts-noto:all-20201225-1
VM arguments: [--module-path=/usr/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]


cache.capabilities1637351842=1657209865
cache.motd.html=1657210156
cache.motd.html.java=11.0.14
cache.motd.html.lang=En:
cache.motd.html.version=18463
draw.rawgps.lines=-1
gui.geometry=x=460,y=230,width=1000,height=740
gui.maximized=true
imagery.entries=[{max-zoom=22, min-zoom=1, noTileHeaders={"X-VE-Tile-Info":["no-tile"]}, noTileChecksums={"MD5":["c13269481c73de6e18589f9fbc3bdf7e"]}, metadataHeaders={"X-VE-TILEMETA-CaptureDatesRange":"Capture Date"}, transparent=true, minimumTileExpire=3600, name=Bing aerial imagery, id=Bing, type=bing, url=https://www.bing.com/maps/, permission-reference-url=https://wiki.openstreetmap.org/wiki/Bing_Maps, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=photo},
  {max-zoom=22, noTileHeaders={"Etag":["\"10i954m13i2\""]}, noTileChecksums={"MD5":["f27d9de7f80c13501f470595e327aa6d"]}, transparent=true, minimumTileExpire=3600, name=Esri World Imagery, id=EsriWorldImagery, type=tms, url=https://{switch:services,server}.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/tile/{zoom}/{y}/{x}, attribution-text=Terms & Feedback, attribution-url=https://wiki.openstreetmap.org/wiki/Esri, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=photo},
  {max-zoom=22, transparent=true, minimumTileExpire=3600, name=Esri World Imagery (Clarity) Beta, id=EsriWorldImageryClarity, type=tms, url=https://clarity.maptiles.arcgis.com/arcgis/rest/services/World_Imagery/MapServer/tile/{zoom}/{y}/{x}, attribution-text=Terms & Feedback, attribution-url=https://wiki.openstreetmap.org/wiki/Esri, permission-reference-url=https://github.com/osmlab/editor-layer-index/pull/358#issuecomment-361416110, cookies=, icon=data:image/png;base64,iVBORw0..., description=Esri archive imagery that may be clearer and more accurate than the default layer., customHttpHeaders={}, category=photo},
  {max-zoom=22, noTileHeaders={"ETag":["\"336b022ed883bc72347a637634e490d4\"|\"067736a547cafe90014b4e59b6510abe\"|\"ee1f6802b0234046b553cbbc672ac7d9\"|\"9f5a2f1d7cc131e58befc2052c71c827\""]}, noTileChecksums={"MD5":["58e78313d04adf0ea64b8de8590c3d46"]}, transparent=true, minimumTileExpire=3600, name=Mapbox Satellite, id=Mapbox, type=tms, url=https://{switch:a,b,c,d}.tiles.mapbox.com/v4/mapbox.satellite/{zoom}/{x}/{y}.jpg?access_token={apikey}, attribution-text=Terms & Feedback, attribution-url=https://www.mapbox.com/about/maps/, permission-reference-url=https://wiki.openstreetmap.org/wiki/Vertical_Aerial_Photographs#DigitalGlobe_.2F_MapBox, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=photo},
  {max-zoom=22, noTileChecksums={"MD5":["08d6916814b216570e5241732c41d5e5"]}, valid-georeference=true, transparent=true, minimumTileExpire=3600, name=Maxar Premium Imagery, id=Maxar-Premium, type=tms, url=https://services.digitalglobe.com/earthservice/tmsaccess/tms/1.0.0/DigitalGlobe:ImageryTileService@EPSG:3857@jpg/{zoom}/{x}/{-y}.jpg?connectId={apikey}, attribution-text=Terms & Feedback, attribution-url=https://wiki.openstreetmap.org/wiki/DigitalGlobe, cookies=, icon=data:image/png;base64,iVBORw0..., description=Maxar Premium is a mosaic composed of Maxar basemap with select regions filled with +Vivid or custom area of interest imagery, 50cm resolution or better, and refreshed more frequently with ongoing updates., customHttpHeaders={}, category=photo},
  {max-zoom=19, valid-georeference=true, modTileFeatures=true, transparent=true, minimumTileExpire=3600, name=OpenStreetMap Carto (Standard), id=standard, type=tms, url=https://tile.openstreetmap.org/{zoom}/{x}/{y}.png, attribution-text=© OpenStreetMap contributors, attribution-url=https://www.openstreetmap.org/, permission-reference-url=https://wiki.osmfoundation.org/wiki/Terms_of_Use, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=osmbasedmap}
]
imagery.layers.default=[Bing, EsriWorldImagery, EsriWorldImageryClarity, Mapbox, Maxar-Premium, standard]
josm.version=18463
mappaint.renderer-class-name=org.openstreetmap.josm.data.osm.visitor.paint.StyledMapRenderer
mappaint.style.known-defaults=[resource://styles/standard/elemstyles.mapcss, resource://styles/standard/potlatch2.mapcss]
mirror.https://josm.openstreetmap.de/maps=[1657209867816, <josm.cache>/mirror_https___josm.openstreetmap.de_maps]
mirror.https://josm.openstreetmap.de/remote/geofabrik-index-v1-nogeom.json=[1657209864830, <josm.cache>/mirror_https___josm.openstreetmap.de_remote_geofabrik-index-v1-nogeom.json]
preferences.reset.draw.rawgps.lines=true

With openjdk-17-jre from backports:

$ JAVACMD=/usr/lib/jvm/java-17-openjdk-amd64/bin/java /usr/bin/josm

Revision:18463
Is-Local-Build:false
Build-Date:1970-01-10 17:37:24
Debian-Release:0.0.svn18463+dfsg-1~bpo11+1
Build-Name:Debian

Identification: JOSM/1.5 (18463 Debian en) Linux Debian GNU/Linux 11 (bullseye)
Memory Usage: 202 MB / 984 MB (104 MB allocated, but free)
Java version: 17.0.2+8-Debian-1deb11u1, Debian, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1200 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1200
Best cursor sizes: 16×16→16×16, 32×32→32×32
Environment variable LANG: en_US.UTF-8
System property file.encoding: UTF-8
System property sun.jnu.encoding: UTF-8
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
Java ATK Wrapper package: libatk-wrapper-java:all-0.40.0-2~bpo11+1
libcommons-compress-java: libcommons-compress-java:all-1.20-1
fonts-noto: fonts-noto:all-20201225-1
VM arguments: [--module-path=/usr/share/openjfx/lib, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, -Djosm.restart=true, -Djava.net.useSystemProxies=true, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]


cache.capabilities1637351842=1657209865
cache.motd.html=1657209864
cache.motd.html.java=17.0.2
cache.motd.html.lang=En:
cache.motd.html.version=18463
draw.rawgps.lines=-1
gui.geometry=x=460,y=230,width=1000,height=740
gui.maximized=true
imagery.entries=[{max-zoom=22, min-zoom=1, noTileHeaders={"X-VE-Tile-Info":["no-tile"]}, noTileChecksums={"MD5":["c13269481c73de6e18589f9fbc3bdf7e"]}, metadataHeaders={"X-VE-TILEMETA-CaptureDatesRange":"Capture Date"}, transparent=true, minimumTileExpire=3600, name=Bing aerial imagery, id=Bing, type=bing, url=https://www.bing.com/maps/, permission-reference-url=https://wiki.openstreetmap.org/wiki/Bing_Maps, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=photo},
  {max-zoom=22, noTileHeaders={"Etag":["\"10i954m13i2\""]}, noTileChecksums={"MD5":["f27d9de7f80c13501f470595e327aa6d"]}, transparent=true, minimumTileExpire=3600, name=Esri World Imagery, id=EsriWorldImagery, type=tms, url=https://{switch:services,server}.arcgisonline.com/arcgis/rest/services/World_Imagery/MapServer/tile/{zoom}/{y}/{x}, attribution-text=Terms & Feedback, attribution-url=https://wiki.openstreetmap.org/wiki/Esri, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=photo},
  {max-zoom=22, transparent=true, minimumTileExpire=3600, name=Esri World Imagery (Clarity) Beta, id=EsriWorldImageryClarity, type=tms, url=https://clarity.maptiles.arcgis.com/arcgis/rest/services/World_Imagery/MapServer/tile/{zoom}/{y}/{x}, attribution-text=Terms & Feedback, attribution-url=https://wiki.openstreetmap.org/wiki/Esri, permission-reference-url=https://github.com/osmlab/editor-layer-index/pull/358#issuecomment-361416110, cookies=, icon=data:image/png;base64,iVBORw0..., description=Esri archive imagery that may be clearer and more accurate than the default layer., customHttpHeaders={}, category=photo},
  {max-zoom=22, noTileHeaders={"ETag":["\"336b022ed883bc72347a637634e490d4\"|\"067736a547cafe90014b4e59b6510abe\"|\"ee1f6802b0234046b553cbbc672ac7d9\"|\"9f5a2f1d7cc131e58befc2052c71c827\""]}, noTileChecksums={"MD5":["58e78313d04adf0ea64b8de8590c3d46"]}, transparent=true, minimumTileExpire=3600, name=Mapbox Satellite, id=Mapbox, type=tms, url=https://{switch:a,b,c,d}.tiles.mapbox.com/v4/mapbox.satellite/{zoom}/{x}/{y}.jpg?access_token={apikey}, attribution-text=Terms & Feedback, attribution-url=https://www.mapbox.com/about/maps/, permission-reference-url=https://wiki.openstreetmap.org/wiki/Vertical_Aerial_Photographs#DigitalGlobe_.2F_MapBox, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=photo},
  {max-zoom=22, noTileChecksums={"MD5":["08d6916814b216570e5241732c41d5e5"]}, valid-georeference=true, transparent=true, minimumTileExpire=3600, name=Maxar Premium Imagery, id=Maxar-Premium, type=tms, url=https://services.digitalglobe.com/earthservice/tmsaccess/tms/1.0.0/DigitalGlobe:ImageryTileService@EPSG:3857@jpg/{zoom}/{x}/{-y}.jpg?connectId={apikey}, attribution-text=Terms & Feedback, attribution-url=https://wiki.openstreetmap.org/wiki/DigitalGlobe, cookies=, icon=data:image/png;base64,iVBORw0..., description=Maxar Premium is a mosaic composed of Maxar basemap with select regions filled with +Vivid or custom area of interest imagery, 50cm resolution or better, and refreshed more frequently with ongoing updates., customHttpHeaders={}, category=photo},
  {max-zoom=19, valid-georeference=true, modTileFeatures=true, transparent=true, minimumTileExpire=3600, name=OpenStreetMap Carto (Standard), id=standard, type=tms, url=https://tile.openstreetmap.org/{zoom}/{x}/{y}.png, attribution-text=© OpenStreetMap contributors, attribution-url=https://www.openstreetmap.org/, permission-reference-url=https://wiki.osmfoundation.org/wiki/Terms_of_Use, cookies=, icon=data:image/png;base64,iVBORw0..., customHttpHeaders={}, category=osmbasedmap}
]
imagery.layers.default=[Bing, EsriWorldImagery, EsriWorldImageryClarity, Mapbox, Maxar-Premium, standard]
josm.version=18463
mappaint.renderer-class-name=org.openstreetmap.josm.data.osm.visitor.paint.StyledMapRenderer
mappaint.style.known-defaults=[resource://styles/standard/elemstyles.mapcss, resource://styles/standard/potlatch2.mapcss]
mirror.https://josm.openstreetmap.de/maps=[1657209867816, <josm.cache>/mirror_https___josm.openstreetmap.de_maps]
mirror.https://josm.openstreetmap.de/remote/geofabrik-index-v1-nogeom.json=[1657209864830, <josm.cache>/mirror_https___josm.openstreetmap.de_remote_geofabrik-index-v1-nogeom.json]
preferences.reset.draw.rawgps.lines=true

[sebastic]

Replying to taylor.smock:

/bin/bash should work everywhere, on systems where it doesn't further investigation is needed, not a change to the shebang of josm.

I'm probably just going to switch to /usr/bin/env bash, since it looks like that will probably work on the BSDs. I haven't tested the rest of the script on BSD, but it won't just error out immediately.

#!/bin/bash is what the josm launcher should use.

The launcher included in the JOSM source tree was only used by the Ubuntu package (for https://josm.openstreetmap.de/apt) and the official Debian package. That's why the alternatives system and dpkg were unconditional.

The openSUSE package linked on the Download page uses its own launcher. As do josm-javaws & josm-svn in Arch, and the josm ports in FreeBSD & OpenBSD.

The josm launch in the JOSM source tree doesn't need to care about any of those.

[taylor.smock]

Replying to sebastic:

#!/bin/bash is what the josm launcher should use.

The launcher included in the JOSM source tree was only used by the Ubuntu package (for https://josm.openstreetmap.de/apt) and the official Debian package. That's why the alternatives system and dpkg were unconditional.

The openSUSE package linked on the Download page uses its own launcher. As do josm-javaws & josm-svn in Arch, and the josm ports in FreeBSD & OpenBSD.

The josm launch in the JOSM source tree doesn't need to care about any of those.

Do you have any idea how many tickets we close because a downstream package maintainer doesn't add the appropriate jvm arguments? I really want to be able to tell downstream maintainers to "use this script" so that we don't have a new ticket every few days where the problem is the jvm arguments.

That is why the start script no longer unconditionally requires dpkg and alternatives. They are still used, if present, but they aren't necessary.

The biggest contributor seems to be Arch, although there are some Ubuntu users with the same issue. They may be running into a similar issue to skyper, in that they are only getting /bin/java as the interpreter (for whatever reason, the start script used to use the java command path to determine the java version, instead of using java -version). By using java -version, we fix the issue where /bin/java is the java binary, since we don't depend upon its path. However, the fact that we are getting /bin/java as a binary when some of the other paths exist is a problem. And that seems to be specific to /bin/bash as the interpreter. Since /bin/bash exhibits different behavior, I am disinclined to use it in the #!.

Also, as an FYI, the unofficial flatpak uses the start script.

[sebastic]

I really want to be able to tell downstream maintainers to "use this script" so that we don't have a new ticket every few days where the problem is the jvm arguments.

That's why you only need to revert the shebang change, not the other changes that made the Debian bits optional.

So far it hasn't been possible to reproduce the issues that triggered your change to move away from /bin/bash, there is no proof it solves anything.

[taylor.smock]

Replying to sebastic:

That's why you only need to revert the shebang change, not the other changes that made the Debian bits optional.

So far it hasn't been possible to reproduce the issues that triggered your change to move away from /bin/bash, there is no proof it solves anything.

Do you have any concrete objections to #!/usr/bin/env bash?

[sebastic]

They may be running into a similar issue to skyper, in that they are only getting /bin/java as the interpreter (for whatever reason, the start script used to use the java command path to determine the java version, instead of using java -version).

The reason is that the openjdk packages that were supported by the launcher (the openjdk Debian packages) have the version in their path.

The launcher loops through the list of supported JREs (if JAVACMD is not set in the environment or though /etc/default/josm):

        # LTS versions in decreased order
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-$ARCH/bin/java"
        # Released versions in decreased order
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-16-openjdk/bin/java /usr/lib/jvm/java-16-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-15-openjdk/bin/java /usr/lib/jvm/java-15-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-14-openjdk/bin/java /usr/lib/jvm/java-14-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-13-openjdk/bin/java /usr/lib/jvm/java-13-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-12-openjdk/bin/java /usr/lib/jvm/java-12-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-10-openjdk/bin/java /usr/lib/jvm/java-10-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-9-openjdk/bin/java /usr/lib/jvm/java-9-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-8-openjdk/bin/java /usr/lib/jvm/java-8-openjdk-$ARCH/bin/java"
        # Development version(s)
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-18-openjdk/bin/java /usr/lib/jvm/java-18-openjdk-$ARCH/bin/java"

During the loop it checks if what the /etc/alternatives/java symlink points to (ALTERNATIVE_JDK) matches the path in the list, if so it uses that path for JAVACMD.

Because JAVACMD is then set it doesn't bother with any of the other supported JREs.

If whatever /etc/alternatives/java points to is not among the list of supported JREs, the first one in that list that is found to exist and be executable is used to set JAVACMD.

If none of the JREs in the list are found to be executable an error is shown and the launcher exits with status 1.

If an executable java was found (i.e. JAVACMD is set), the path in JAVACMD (e.g. /usr/lib/jvm/java-11-openjdk-amd64/bin/java) is tested with a regex, if it contains java-9 or java-10 anywhere in the path (e.g. /usr/lib/jvm/java-9-openjdk/bin/java or /usr/lib/jvm/java-10-openjdk-amd64/bin/java were found) --add-modules java.activation,java.se.ee is prepended to JAVAOPTS.
If java-1 is found anywhere in the path (e.g /usr/lib/jvm/java-11-openjdk-amd64/bin/java or /usr/lib/jvm/java-17-openjdk-amd64/bin/java), then a whole bunch of options are prepended to JAVAOPTS:

        JAVA_OPTS="--module-path /usr/share/openjfx/lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web $JAVA_OPTS"
        JAVA_OPTS="$JAVA_OPTS --add-exports=java.base/sun.security.action=ALL-UNNAMED"
        JAVA_OPTS="$JAVA_OPTS --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED"
        JAVA_OPTS="$JAVA_OPTS --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED"

This logic only fails when JAVACMD is not a symlink to /etc/alternatives/java as on Debian systems, or the path in JAVACMD does not include java-<NN> in its path (e.g. if you just unpack the JDK tarballs from adoptium.net or java.com). So using $JAVACMD -version makes the version detection work when it cannot be determined from the path, but you're slowing down the startup of JOSM because it has to start java twice, once for the version detection and once to actually start JOSM.

The cat in java_version() doesn't add anything, this suffices:

${1} -version 2>&1 | head -n1 | awk -F'"' '{print $2}' | awk -F'.' '{print $1}'

And this shellcheck suggestion should be adopted:

In /usr/bin/josm line 75:
    JAVA_VERSION=$(java_version ${JAVACMD})
                                ^--------^ SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: 
    JAVA_VERSION=$(java_version "${JAVACMD}")

[sebastic]

Replying to taylor.smock:

Replying to sebastic:

That's why you only need to revert the shebang change, not the other changes that made the Debian bits optional.

So far it hasn't been possible to reproduce the issues that triggered your change to move away from /bin/bash, there is no proof it solves anything.

Do you have any concrete objections to #!/usr/bin/env bash?

It is a useless change. /bin/bash is the canonical location since pretty much forever, the countless scripts out in the wild using #!/bin/bash & #!/bin/sh is one of the primary concerns in the usrmerge debate, regardless of how usrmerge is implemented, that will have to keep working even when the executable actually lives under /usr.

/usr/bin/env is a layer of indirection that makes no sense for shells, users don't generally have a bunch of different versions of that installed like is more common for python interpreters.

[taylor.smock]

Replying to sebastic:

The cat in java_version() doesn't add anything, this suffices:

${1} -version 2>&1 | head -n1 | awk -F'"' '{print $2}' | awk -F'.' '{print $1}'

And this shellcheck suggestion should be adopted:

In /usr/bin/josm line 75:
    JAVA_VERSION=$(java_version ${JAVACMD})
                                ^--------^ SC2086 (info): Double quote to prevent globbing and word splitting.

Did you mean: 
    JAVA_VERSION=$(java_version "${JAVACMD}")

These are both useful feedback. I really wish I had a list of people to cc on the original ticket. Neither one is a crasher for most people, so I'm not going to change anything right now (remind me in a week, if I forget).

Replying to sebastic:

It is a useless change. /bin/bash is the canonical location since pretty much forever, the countless scripts out in the wild using #!/bin/bash & #!/bin/sh is one of the primary concerns in the usrmerge debate, regardless of how usrmerge is implemented, that will have to keep working even when the executable actually lives under /usr.
/usr/bin/env is a layer of indirection that makes no sense for shells, users don't generally have a bunch of different versions of that installed like is more common for python interpreters.

This sounds more like a "I don't have a concrete reason to avoid /usr/bin/env bash". If we can figure out why skyper's machine was exhibiting different behavior with /bin/bash and /usr/bin/bash, I won't mind changing it back. Until then, /usr/bin/env bash should work for everyone.

As an aside, with r18512, this is no longer a ticket affecting a group of users in a major way. The original problem ("cannot start JOSM on non-usrmerged machines") has been fixed, and we are now discussing a problem of "I don't like /usr/bin/env bash in my scripts".

[sebastic]

I really wish I had a list of people to cc on the original ticket.

Finding the maintainers of josm packages is not very hard, it's listed on the packaging pages and contacts details are generally recorded in the packaging:

• ​https://tracker.debian.org/pkg/josm (Maintainer: Debian GIS Project, Uploaders: Bas Couwenberg, Mònica Ramírez Arceda, David Paleino)
  • ​https://salsa.debian.org/debian-gis-team/josm/-/blob/master/debian/control (Uploaders field lists email addresses)

• ​https://cgit.freebsd.org/ports/log/astro/josm (Dmitry Marakasov made all the recent changes)
  • ​https://cgit.freebsd.org/ports/tree/astro/josm/Makefile (Maintainer field lists contact email)

• ​https://openports.se/geo/josm (Maintained by: Holger Mikolon)
  • ​http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/geo/josm/Makefile?rev=1.50&content-type=text/x-cvsweb-markup (Maintainer field lists contact email)

• ​https://aur.archlinux.org/packages/josm-javaws (Maintainer: thibaultmol)
  • ​https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=josm-javaws (Lists email address)
• ​https://aur.archlinux.org/packages/josm-svn (Maintainer: SammysHP)
  • ​https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=josm-svn (Lists email address)

Finding contributors to the josm launcher only requires inspecting the SVN log for the file.

[...] "I don't like /usr/bin/env bash in my scripts".

The problem is that #!/usr/bin/env bash is wrong, not that I don't like it.

I'm sad that we'll have to carry a patch in the Debian package in perpetuity to use a sane shebang for the shell interpreter, because you're unwilling to listen to the packaging experts. /bin/bash is required for Debian policy (​§ 10.4) compliance, you may be able to ignore that, the maintainers of the Debian package can't:

If a shell script requires non-POSIX.1-2017 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked “Essential”, as in the case of bash).

You may wish to restrict your script to POSIX.1-2017 features plus the above set when possible so that it may use /bin/sh as its interpreter. Checking your script with checkbashisms from the devscripts package or running your script with an alternate shell such as posh may help uncover violations of the above requirements. If in doubt whether a script complies with these requirements, use /bin/bash.

If you'd run lintian on your Ubuntu packages it would raise: wrong-path-for-interpreter /usr/bin/bash != /bin/bash.

[taylor.smock]

Replying to sebastic:

I really wish I had a list of people to cc on the original ticket.

Finding the maintainers of josm packages is not very hard, it's listed on the packaging pages and contacts details are generally recorded in the packaging:

I checked arch (uses custom script) and suse (also uses custom script). When I've looked at the debian package in the past, it was severely out of date for anything besides backports/latest, which (sorry) made me believe that it was largely unmaintained.

I've tried communicating with the arch maintainer via the arch bug tracker. I haven't had much success with that.

Finding contributors to the josm launcher only requires inspecting the SVN log for the file.

Looking at the history, it does look like you contributed in r15944. I will note that it was two years ago, but I guess I should have seen that and cc'd you.

[...] "I don't like /usr/bin/env bash in my scripts".

The problem is that #!/usr/bin/env bash is wrong, not that I don't like it.

I'm sad that we'll have to carry a patch in the Debian package in perpetuity to use a sane shebang for the shell interpreter, because you're unwilling to listen to the packaging experts. /bin/bash is required for Debian policy (​§ 10.4) compliance, you may be able to ignore that, the maintainers of the Debian package can't:

And my problem is that we have a frequent contributor (skyper) who has experienced differences between /bin/bash and /usr/bin/bash on a Debian system. If that is fixed, I have no problem changing it back. Assuming diff wasn't tampered with, they were the same binary, which is really confusing. My assumption, until proven otherwise, is that something, somewhere is causing /bin/bash to be special cased.

If a shell script requires non-POSIX.1-2017 features from the shell interpreter other than those listed above, the appropriate shell must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked “Essential”, as in the case of bash).

You may wish to restrict your script to POSIX.1-2017 features plus the above set when possible so that it may use /bin/sh as its interpreter. Checking your script with checkbashisms from the devscripts package or running your script with an alternate shell such as posh may help uncover violations of the above requirements. If in doubt whether a script complies with these requirements, use /bin/bash.

I'm not seeing any prohibitions here over /usr/bin/env bash "The appropriate shell must be specified in the first line of the script", for example "#!/bin/bash". We are specifying bash, although we are using /usr/bin/env to start it to work around what appears to be a Debian bug.
This is probably a matter of interpretation ("The specification of the shell must be the absolute path to the shell" versus "just specify which shell should be used").

If you'd run lintian on your Ubuntu packages it would raise: wrong-path-for-interpreter /usr/bin/bash != /bin/bash.

[taylor.smock]

@skyper: On my fresh debian vm, there is a bashbug script. Have you reported the bash bug you encountered?

[sebastic]

I checked arch (uses custom script) and suse (also uses custom script). When I've looked at the debian package in the past, it was severely out of date for anything besides backports/latest, which (sorry) made me believe that it was largely unmaintained.

How is does having an up to date josm in backports translate to being largely unmaintained?

You're not paying attention, first you fail to understand what the launcher scripts does, and then you have the gall to ignore the input from the packaging experts that do understand...

My assumption, until proven otherwise, is that something, somewhere is causing /bin/bash to be special cased.

Don't make assumptions. Test your hypotheses.

We need to be able to reproduce the issue experience by skyper before making changes.

You are poking in the dark hoping to prod the right bit.

We are specifying bash, although we are using /usr/bin/env to start it to work around what appears to be a Debian bug.

/usr/bin/env is not the bash interpreter, hence the shebang is wrong. env is a different executable that uses execvp() to execute bash instead of executing it directly via the shebang.

[taylor.smock]

Replying to sebastic:

I checked arch (uses custom script) and suse (also uses custom script). When I've looked at the debian package in the past, it was severely out of date for anything besides backports/latest, which (sorry) made me believe that it was largely unmaintained.

How is does having an up to date josm in backports translate to being largely unmaintained?

JOSM revisions (for stable and newer):

• ​stable: r17428
• ​stable-backports: r18463 (users have to do extra stuff for this, from what I understand, so the version in stable is IMO unmaintained).
• ​bookworm: r18463

From ​https://backports.debian.org/,

Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!

So we have a potentially unsupported package in stable-backports, and the version in tested could just as easily be autoupdated, and considering that it is fairly easy to know when to update JOSM using tested, I don't find it unreasonable to assume that distributions are using it to auto update.

You're not paying attention, first you fail to understand what the launcher scripts does, and then you have the gall to ignore the input from the packaging experts that do understand...

I'm not ignoring input from packagers. I also understand what the goal of the launcher script is ("start josm with all required options") and also what it did ("start josm with all required options with the latest LTS/supported version of Java if (a) dpkg exists, (b) there is at least one non-headless version of java installed, and (c) if the java path has the java version number", otherwise start JOSM with no options with whatever binary we can find). There are a few more things in there (like reading a user config file), but that is the important bits.
I'm also not willing to make changes right now that are not fixing a broken thing that is preventing large numbers of users from starting/using JOSM. Changing #!/usr/bin/bash to #!/usr/bin/env bash would have minimal breakage for ordinary users running JOSM. Switching to #!/bin/bash could cause more breakage, so I'm unwilling to do that change until next Monday, at the earliest, regardless of any other consideration (like bug reporters who have been around awhile claiming that #!/bin/bash has issues).
Like I said in comment:24

These are both useful feedback. I really wish I had a list of people to cc on the original ticket. Neither one is a crasher for most people, so I'm not going to change anything right now (remind me in a week, if I forget).

I'm open to feedback. I'm just unwilling to act on any of it until next week, unless something is severely broken. I do not consider "we prefer #!/bin/bash over #!/usr/bin/env bash" to be something that is severely broken. Maybe bad practice, but not broken.

My assumption, until proven otherwise, is that something, somewhere is causing /bin/bash to be special cased.

Don't make assumptions. Test your hypotheses.

I did. Remotely with skyper. As with all remote debugging, there was room for error. However, he did report that #!/bin/bash did not work appropriately while #!/usr/bin/bash or #!/usr/bin/env bash did.

We need to be able to reproduce the issue experience by skyper before making changes.
You are poking in the dark hoping to prod the right bit.

Unfortunately, yes. With a bit of help from someone else. I hate doing this, by the way.

We are specifying bash, although we are using /usr/bin/env to start it to work around what appears to be a Debian bug.

/usr/bin/env is not the bash interpreter, hence the shebang is wrong. env is a different executable that uses execvp() to execute bash instead of executing it directly via the shebang.

Again, this is a matter of interpretation. I can see how the text can be interpreted that way, but it isn't specifying that the shebang executable must be the path to the binary. If your interpretation is correct, then the text should be updated to read something like:

If a shell script requires non-POSIX.1-2017 features from the shell interpreter other than those listed above, the appropriate shell executable path must be specified in the first line of the script (e.g., #!/bin/bash) and the package must depend on the package providing the shell (unless the shell package is marked “Essential”, as in the case of bash).

Right now, we are arguing over the shebang line. Maybe you are right, maybe you aren't. TBH, if I didn't have a credible report of #!/bin/bash not working properly, I would make the change (I wouldn't have changed it from #!/bin/bash in the first place).

[sebastic]

If you knew what you were doing you wouldn't have changed the shebang in the first place.

So we have a potentially unsupported package in stable-backports, and the version in tested could just as easily be autoupdated, and considering that it is fairly easy to know when to update JOSM using tested, I don't find it unreasonable to assume that distributions are using it to auto update.

You're making assumptions again. And that's where you wrong.

Reproducing issues is indeed not fun. But changing the launcher based on the issues of a single user is wrong. It would have affected far more users if the launcher was broken on usrmerge systems, you'd have many more bugreports about it.

Can't you run VMs on your systems? That's the go-to tool to reproduce other environments. KVM is free, and so is VirtualBox.

[taylor.smock]

Replying to sebastic:

Reproducing issues is indeed not fun. But changing the launcher based on the issues of a single user is wrong. It would have affected far more users if the launcher was broken on usrmerge systems, you'd have many more bugreports about it.

Then why haven't we had any before this ticket? The change you are complaining about has been present in our josm-latest packages for about 20 days.

Can't you run VMs on your systems? That's the go-to tool to reproduce other environments. KVM is free, and so is VirtualBox.

Yes. And I've been checking with minimal debian/ubuntu installs. On a new debian install, /usr/bin/bash was not a problem (FTR, I've had computer crashes when running a DE in the VM, but the final start command is something I can check elsewhere).

[taylor.smock]

For reference, #22198 and #22199 (fixed in r18513) is an example of why I am somewhat leary about making changes directly around a release that are not strictly necessary. I'm going through the hotfix release process now for that.

[sebastic]

Then why haven't we had any before this ticket? The change you are complaining about has been present in our josm-latest packages for about 20 days.

Nobody has used josm-latest on non-usrmerge systems in the past 20 days.

Why did you get this bugreport today? Because the new tested snapshot got packaged and the maintainer noticed changes that were obviously wrong.

For reference, #22198 and #22199 (fixed in r18513) is an example of why I am somewhat leary about making changes directly around a release that are not strictly necessary. I'm going through the hotfix release process now for that.

That's why you need to reproduce issues.

tested may carry that name because it used to be that latest had actual real-world use and the changes got tested that way, that seems to no longer be the case (at least where the josm launcher is concerned which is almost exclusively used by the Ubuntu package). The official Debian package tracks the tested snapshots, users that want latest on Debian can use the josm-installer package to use the jars from josm.openstreetmap.de and have those updated automatically. josm-installer has some users according to popcon, but nothing compared to the josm package.

[taylor.smock]

Replying to sebastic:

Then why haven't we had any before this ticket? The change you are complaining about has been present in our josm-latest packages for about 20 days.

Nobody has used josm-latest on non-usrmerge systems in the past 20 days.

Why did you get this bugreport today? Because the new tested snapshot got packaged and the maintainer noticed changes that were obviously wrong.

And once said maintainer noticed and reported, a fix that will not break systems was applied. I know (again), you do not like #!/usr/bin/env bash, but will work for everyone who doesn't have a borked $PATH, which is more than I can say about #!/bin/bash.

For reference, #22198 and #22199 (fixed in r18513) is an example of why I am somewhat leary about making changes directly around a release that are not strictly necessary. I'm going through the hotfix release process now for that.

That's why you need to reproduce issues.

In that case, it was very easy to reproduce. It wasn't the start script which is OS dependent, where the user might have any number of random packages installed and configurations applied in /etc. I'll note that we have had several reports from Ubuntu systems which indicated that either the user was using java -jar josm-tested.jar or the start script was not working properly. That was a factor in my consideration for the report from skyper.

I would have liked to ssh into his system and checked to see if I could figure out what was going on, but I generally believe giving strangers on the internet access to your computer to be a bad idea, so I didn't ask.

tested may carry that name because it used to be that latest had actual real-world use and the changes got tested that way, that seems to no longer be the case (at least where the josm launcher is concerned which is almost exclusively used by the Ubuntu package). The official Debian package tracks the tested snapshots, users that want latest on Debian can use the josm-installer package to use the jars from josm.openstreetmap.de and have those updated automatically. josm-installer has some users according to popcon, but nothing compared to the josm package.

In this case, I think it still gets real world use on usrmerge systems. Debian is (AFAICT) the only distribution which did a halfway transition thing to merge /usr, where some users have different configurations from other users.

Again, to reiterate, I am open to changing it back to #!/bin/bash as soon as either (a) skyper confirms it is no longer an issue on his system, (b) an upstream bug in bash is opened, or (c) a significant issue is found with #!/usr/bin/env bash.

Thus far, only (c) has had any possible indications, which comes down to "it doesn't conform to an interpretation of Debian package guidelines". Which isn't a significant issue. It is an issue, I'll give you that, but it isn't one that justifies breaking a freeze.

With that said, I am very tempted to start ignoring this ticket, if only because we seem to be talking by each other.

You have been very insistent that #!/bin/bash is the only right way to do the shebang line. I have been very insistent that a user with a long history on JOSM trac has had issues with that shebang line, and as such I am unwilling to change it back during what I consider to be a critical bug fix only time. I have been open to changing it back once I am certain we aren't going to be flooded with major bug reports, for which I tend to allocate a few days to prior and post release (in other words, Monday next week).

[skyper]

Hi, please calm down, we all try to support the development of josm at our best, so do not take it personally.
Sadly, I do not have that much time for josm, atm, though I still try my best to report and to reproduce problems.
Regarding the missing CC, I should have add "sebastic" myself and probably should have tested the official Debian packages. I am sorry, I missed that. Is it possible to add "sebastic" to the cc-list of the component Ubuntu package ?

Talking about this ticket, I did reproduce #22157 on a Ubuntu 22.04 Live system and I am willing to try suggestions but, sorry, I will not allow to ssh onto my system any person who I do not know in person.
I just try the josm package from sid, josm/0.0.svn18511+dfsg-1, and it is working, see ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014516. Thanks for the fast fix, Sebastiaan.

Replying to taylor.smock:

@skyper: On my fresh debian vm, there is a bashbug script. Have you reported the bash bug you encountered?

No, I was not aware of bashbug and additionally I was not sure if it is a bug of bash. Should I still report it?

[taylor.smock]

Replying to skyper:

Hi, please calm down, we all try to support the development of josm at our best, so do not take it personally.
Sadly, I do not have that much time for josm, atm, though I still try my best to report and to reproduce problems.
Regarding the missing CC, I should have add "sebastic" myself and probably should have tested the official Debian packages. I am sorry, I missed that. Is it possible to add "sebastic" to the cc-list of the component Ubuntu package ?

This would be something to ask stoecker/Don-vip.

Talking about this ticket, I did reproduce #22157 on a Ubuntu 22.04 Live system and I am willing to try suggestions but, sorry, I will not allow to ssh onto my system any person who I do not know in person.

Good to know (we have a starting point for debugging). I was unable to reproduce on a minimal debian install, but it was a minimal install.
There is a reason why I didn't ask for remote access (I have a side job fixing other peoples' computers, and so many problems could be avoided if people didn't give strangers remote access, or just didn't give anyone remote access at all).

I just try the josm package from sid, josm/0.0.svn18511+dfsg-1, and it is working, see ​https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014516. Thanks for the fast fix, Sebastiaan.

Working, as in starting? Or working, as in you could not reproduce #22157? If the former, r18153 fixed the #!/usr/bin/bash problem (changed to #!/usr/bin/env bash which is what has caused this discussion to spiral out of control). If the latter, I am going to have fun debugging.

Replying to taylor.smock:

@skyper: On my fresh debian vm, there is a bashbug script. Have you reported the bash bug you encountered?

No, I was not aware of bashbug and additionally I was not sure if it is a bug of bash. Should I still report it?

I honestly don't know. It is an unexpected behavior difference between /bin/bash and /usr/bin/bash, but the only way I can think for that to happen is if something is special casing one of the two paths. (Example: dash decides it would be a good idea to override shebangs of #!/bin/bash and run them itself).

[sebastic]

The josm (0.0.svn18511+dfsg-1) package in Debian contains the patch from the OP, it uses #!/bin/bash instead of the #!/usr/bin/bash, and josm (0.0.svn18513+dfsg-1) updates that patch to use #!/bin/bash instead of the #!/usr/bin/env bash.

As long as the openjdk packages from Debian are used, the VM arguments work as expected even before the launcher changes in in r18497.

[sebastic]

On Ubuntu 22.04 usrmerge is used for new installs like on Debian bullseye:

$ ls -l / | grep "> usr"
lrwxrwxrwx   1 root root     7 Apr 21 00:57 bin -> usr/bin
lrwxrwxrwx   1 root root     7 Apr 21 00:57 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Apr 21 00:57 lib32 -> usr/lib32
lrwxrwxrwx   1 root root     9 Apr 21 00:57 lib64 -> usr/lib64
lrwxrwxrwx   1 root root    10 Apr 21 00:57 libx32 -> usr/libx32
lrwxrwxrwx   1 root root     8 Apr 21 00:57 sbin -> usr/sbin

$ ls -l /usr/bin/java /etc/alternatives/java
lrwxrwxrwx 1 root root 43 Jul  9 08:11 /etc/alternatives/java -> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
lrwxrwxrwx 1 root root 22 Jul  9 08:11 /usr/bin/java -> /etc/alternatives/java

The first path in the list of JREs is $JAVA_HOME/bin/java:

JAVA_CMDS="$JAVA_HOME/bin/java"

This translates into /bin/java because JAVA_HOME is not set in the environment, which is a usable path on usrmerge systems but not on non-usrmerge systems (where only /usr/bin/java is available).

On usrmerge systems /bin/java & /usr/bin/java are a symlink to /etc/alternatives/java which in turn is a symlink to a supported JRE which is added to JAVA_CMDS when the dpkg --get-selection tests succeed, specifically this entry:

        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-$ARCH/bin/java"

Because JAVACMD is not set in the environment the list of JREs in JAVA_CMDS get tested to see if one of them is what /etc/alternatives/java points to:

if [ -z "${JAVACMD}" ]; then
    for jcmd in $JAVA_CMDS; do
        if [ "z$ALTERNATIVE_JDK" = "z$(readlink -n -f "$jcmd")" ] && [ -z "${JAVACMD}" ]; then
            JAVACMD="$jcmd"
            break
        fi
    done
fi

This is the case on Ubuntu 22.04 so JAVACMD gets set to /bin/java:

$ bash -x josm --version
+ set -e
++ readlink -n -f /etc/alternatives/java
+ ALTERNATIVE_JDK=/usr/lib/jvm/java-11-openjdk-amd64/bin/java
++ dpkg --print-architecture
+ ARCH=amd64
+ JAVA_CMDS=/bin/java
+ grep 'install$'
+ dpkg --get-selections 'openjdk-*-jre'
+ JAVA_CMDS='/bin/java /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-amd64/bin/java'
+ JAVA_CMDS='/bin/java /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-amd64/bin/java /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-amd64/bin/java'
[...]
+ JAVA_CMDS='/bin/java /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-amd64/bin/java /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-amd64/bin/java /usr/lib/jvm/java-16-openjdk/bin/java /usr/lib/jvm/java-16-openjdk-amd64/bin/java /usr/lib/jvm/java-15-openjdk/bin/java /usr/lib/jvm/java-15-openjdk-amd64/bin/java /usr/lib/jvm/java-14-openjdk/bin/java /usr/lib/jvm/java-14-openjdk-amd64/bin/java /usr/lib/jvm/java-13-openjdk/bin/java /usr/lib/jvm/java-13-openjdk-amd64/bin/java /usr/lib/jvm/java-12-openjdk/bin/java /usr/lib/jvm/java-12-openjdk-amd64/bin/java /usr/lib/jvm/java-10-openjdk/bin/java /usr/lib/jvm/java-10-openjdk-amd64/bin/java /usr/lib/jvm/java-9-openjdk/bin/java /usr/lib/jvm/java-9-openjdk-amd64/bin/java /usr/lib/jvm/java-18-openjdk/bin/java /usr/lib/jvm/java-18-openjdk-amd64/bin/java /usr/lib/jvm/default-java/bin/java /usr/bin/java'
+ '[' -f /etc/default/josm ']'
+ . /etc/default/josm
+ JAVA_OPTS='-Djosm.restart=true -Djava.net.useSystemProxies=true '
+ '[' -z '' ']'
+ for jcmd in $JAVA_CMDS
++ readlink -n -f /bin/java
+ '[' z/usr/lib/jvm/java-11-openjdk-amd64/bin/java = z/usr/lib/jvm/java-11-openjdk-amd64/bin/java ']'
+ '[' -z '' ']'
+ JAVACMD=/bin/java
+ break
+ '[' -z /bin/java ']'
+ '[' /bin/java ']'
+ echo 'Using /bin/java to execute josm.'
Using /bin/java to execute josm.
+ [[ /bin/java =~ java-9 ]]
+ [[ /bin/java =~ java-10 ]]
+ [[ /bin/java =~ java-1 ]]
+ set +e
+ true
+ /bin/java -Djosm.restart=true -Djava.net.useSystemProxies=true -jar /usr/share/josm/josm.jar --version
JOSM/1.5 (18360 Debian en) Linux Ubuntu 22.04 LTS
+ '[' z0 '!=' z9 ']'
+ break

Because the path in JAVACMD doesn't contain java-1 anywhere the VM arguments are not added.

The following patch can be used to resolve this issue:

--- a/usr/bin/josm   2022-01-03 07:42:36.000000000 +0000
+++ b/usr/bin/josm   2022-07-09 08:16:16.739122201 +0000
@@ -40,7 +40,7 @@
 if [ -z "${JAVACMD}" ]; then
     for jcmd in $JAVA_CMDS; do
         if [ "z$ALTERNATIVE_JDK" = "z$(readlink -n -f "$jcmd")" ] && [ -z "${JAVACMD}" ]; then
-            JAVACMD="$jcmd"
+            JAVACMD="$(readlink -n -f "$jcmd")"
             break
         fi
     done

JAVACMD will then be set to the openjdk path that /etc/alternatives/java points to:

$ bash -x /usr/bin/josm --version
+ set -e
++ readlink -n -f /etc/alternatives/java
+ ALTERNATIVE_JDK=/usr/lib/jvm/java-11-openjdk-amd64/bin/java
++ dpkg --print-architecture
+ ARCH=amd64
+ JAVA_CMDS=/bin/java
+ grep 'install$'
+ dpkg --get-selections 'openjdk-*-jre'
+ JAVA_CMDS='/bin/java /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-amd64/bin/java'
+ JAVA_CMDS='/bin/java /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-amd64/bin/java /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-amd64/bin/java'
[...]
+ JAVA_CMDS='/bin/java /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-amd64/bin/java /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-amd64/bin/java /usr/lib/jvm/java-16-openjdk/bin/java /usr/lib/jvm/java-16-openjdk-amd64/bin/java /usr/lib/jvm/java-15-openjdk/bin/java /usr/lib/jvm/java-15-openjdk-amd64/bin/java /usr/lib/jvm/java-14-openjdk/bin/java /usr/lib/jvm/java-14-openjdk-amd64/bin/java /usr/lib/jvm/java-13-openjdk/bin/java /usr/lib/jvm/java-13-openjdk-amd64/bin/java /usr/lib/jvm/java-12-openjdk/bin/java /usr/lib/jvm/java-12-openjdk-amd64/bin/java /usr/lib/jvm/java-10-openjdk/bin/java /usr/lib/jvm/java-10-openjdk-amd64/bin/java /usr/lib/jvm/java-9-openjdk/bin/java /usr/lib/jvm/java-9-openjdk-amd64/bin/java /usr/lib/jvm/java-18-openjdk/bin/java /usr/lib/jvm/java-18-openjdk-amd64/bin/java /usr/lib/jvm/default-java/bin/java /usr/bin/java'
+ '[' -f /etc/default/josm ']'
+ . /etc/default/josm
+ JAVA_OPTS='-Djosm.restart=true -Djava.net.useSystemProxies=true '
+ '[' -z '' ']'
+ for jcmd in $JAVA_CMDS
++ readlink -n -f /bin/java
+ '[' z/usr/lib/jvm/java-11-openjdk-amd64/bin/java = z/usr/lib/jvm/java-11-openjdk-amd64/bin/java ']'
+ '[' -z '' ']'
++ readlink -n -f /bin/java
+ JAVACMD=/usr/lib/jvm/java-11-openjdk-amd64/bin/java
+ break
+ '[' -z /usr/lib/jvm/java-11-openjdk-amd64/bin/java ']'
+ '[' /usr/lib/jvm/java-11-openjdk-amd64/bin/java ']'
+ echo 'Using /usr/lib/jvm/java-11-openjdk-amd64/bin/java to execute josm.'
Using /usr/lib/jvm/java-11-openjdk-amd64/bin/java to execute josm.
+ [[ /usr/lib/jvm/java-11-openjdk-amd64/bin/java =~ java-9 ]]
+ [[ /usr/lib/jvm/java-11-openjdk-amd64/bin/java =~ java-10 ]]
+ [[ /usr/lib/jvm/java-11-openjdk-amd64/bin/java =~ java-1 ]]
+ JAVA_OPTS='--module-path /usr/share/openjfx/lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web -Djosm.restart=true -Djava.net.useSystemProxies=true '
+ JAVA_OPTS='--module-path /usr/share/openjfx/lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web -Djosm.restart=true -Djava.net.useSystemProxies=true  --add-exports=java.base/sun.security.action=ALL-UNNAMED'
+ JAVA_OPTS='--module-path /usr/share/openjfx/lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web -Djosm.restart=true -Djava.net.useSystemProxies=true  --add-exports=java.base/sun.security.action=ALL-UNNAMED --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED'
+ JAVA_OPTS='--module-path /usr/share/openjfx/lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web -Djosm.restart=true -Djava.net.useSystemProxies=true  --add-exports=java.base/sun.security.action=ALL-UNNAMED --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED'
+ set +e
+ true
+ /usr/lib/jvm/java-11-openjdk-amd64/bin/java --module-path /usr/share/openjfx/lib --add-modules java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web -Djosm.restart=true -Djava.net.useSystemProxies=true --add-exports=java.base/sun.security.action=ALL-UNNAMED --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED -jar /usr/share/josm/josm.jar --version
JOSM/1.5 (18360 Debian en) Linux Ubuntu 22.04 LTS
+ '[' z0 '!=' z9 ']'
+ break

Because $JAVACMD -version is used since r18497 to detect the version instead of relying on the path to contain it, the VM arguments also get set for other JREs like ${JAVA_HOME}/bin/java or /usr/lib/jvm/default-java/bin/java.

/usr/bin/josm in the above used #!/bin/bash because that just works as it should.

[sebastic]

The attached patch (josm-launcher.patch) contains various improvements for the JOSM launchers.

From the patch headers:

Description: Improve josm launchers.
 * Use `/bin/bash` instead of `/usr/bin/env bash`
   usrmerge systems have both `/bin/bash` and `/usr/bin/bash`,
   non-usrmerge systems only have `/bin/bash`.
 * Set `ALTERNATIVE_JDK` only if `/etc/alternatives/java` exists.
   While not only Debian based distributions use the alternatives system,
   not all distributions do.
 * Use 4 spaces for indentation consistently.
   Some indentation used tabs, others 2 spaces.
 * Simplify `java_version` function.
   Use `java --version` to get output on `STDOUT` instead of `-version`
   output on `STDERR`.
 * Don't use `command -v` to test whether `dpkg` is available.
   The command may be an alias which results in output like:
   ```
   dpkg is aliased to `donalds-porn-kink-game'
   ```
 * Fix issues reported by `shellcheck`.
   SC2086 is disabled for `$JAVA_OPTS` because that only works unquoted.
Author: Bas Couwenberg <sebastic@debian.org>
Bug: https://josm.openstreetmap.de/ticket/22193

[skyper]

I do not know what changed. There was an update for bash available to day. Anyway, changing back to #!/bin/bash in /usr/bin/josm now works on my system.

[taylor.smock]

Replying to skyper:

I do not know what changed. There was an update for bash available to day. Anyway, changing back to #!/bin/bash in /usr/bin/josm now works on my system.

Good to know. I'll apply @sebastic's patch Monday. I'm going to have to make some changes, since java --version is not available under Java 8, and until we switch to Java 11+ (see #17858), we still technically support Java 8, even if we are strongly pushing Java 11+.

[sebastic]

The bash package hasn't changed in jammy since January:

​https://launchpad.net/ubuntu/+source/bash

Todays bullseye 11.4 point release does contain an updated bash, but the bugfix should be unrelated:

​https://tracker.debian.org/news/1319070/accepted-bash-51-2deb11u1-source-into-proposed-updates-stable-new-proposed-updates/

[sebastic]

Improve josm launchers

[sebastic]

Replying to taylor.smock:

I'm going to have to make some changes, since java --version is not available under Java 8, and until we switch to Java 11+ (see #17858), we still technically support Java 8, even if we are strongly pushing Java 11+.

The patch has been updated to use -version.

[taylor.smock]

In 18515/josm:

Improve josm launchers (patch by sebastic)

Patch notes from sebastic, modified. See #22193.

• Use /bin/bash instead of /usr/bin/env bash usrmerge systems have both /bin/bash and /usr/bin/bash, non-usrmerge systems only have /bin/bash. Distributions that have differing behaviors between /bin/bash and /usr/bin/bash should update/fix their version of bash.
• Set ALTERNATIVE_JDK only if /etc/alternatives/java exists. While not only Debian based distributions use the alternatives system, not all distributions do.
• Use 4 spaces for indentation consistently. Some indentation used tabs, others 2 spaces.
• Simplify java_version function.
• Don't use command -v to test whether dpkg is available. The command may be an alias which results in output like:

dpkg is aliased to 'd*-p*-k*-g*'

• Fix issues reported by shellcheck. SC2086 is disabled for $JAVA_OPTS because that only works unquoted.