For jessie: Trying to understand adtpro.sh

[knghtbrd]

Hey Ivan, I think I mostly have the adtpro.sh script figured out, but maybe you can provide some of your thinking in a few places. This script and the udev rules are basically why it doesn't work with systemd, but I think I have a handle on how to do that. Mostly. Anyway, let's have a look at the diff:

--- ../../adtpro/build/adtprobase.sh    2015-11-02 07:36:07.000000000 -0800
+++ adtpro.sh.txt   2015-10-30 05:47:22.000000000 -0700
@@ -1,5 +1,6 @@
-#!/bin/sh
-#
+#! /bin/bash
+# vim: set tabstop=4 shiftwidth=4 expandtab filetype=sh:
+
 # ADTPro - *nix startup shell script
 #
 # Note:

That's totally on me. :) I actually didn't check the scripts for bashisms, I just made them all use bash since most of the scripts did. Might wanna revert that for this script if it truly isn't necessary. Anyway…

@@ -12,9 +13,9 @@
 #
 # Set default ADTPRO_HOME to be the fully qualified
 # current working directory.
-export ADTPRO_HOME="`dirname \"$0\"`"
-cd "$ADTPRO_HOME"
-export ADTPRO_HOME=`pwd`
+#export ADTPRO_HOME="`dirname \"$0\"`"
+#cd "$ADTPRO_HOME"
+#export ADTPRO_HOME=`pwd`

 # Uncomment and modify one or both of the lines below if you
 # want to specify a particular location for Java or ADTPro.
@@ -24,21 +25,74 @@
 # export MY_JAVA_HOME=/usr/local/java/bin/
 # export ADTPRO_HOME=~/myuser/adtpro

+usageExit () {
+    echo "usage:" 1>&2
+    echo "adtpro.sh [headless] [serial|ethernet|audio|localhost] [serialPortName]" 1>&2
+    exit 1
+}
+
+export ADTPRO_HOME=/usr/local/adtpro
+cd "$ADTPRO_HOME"
+
 OS=`uname`
-OS_ARCH=`uname -p`
+OS_ARCH=`uname -m`
+
+[[ $1 == "headless" ]] && { headless=1; shift; } || headless=
+
+if [[ $1 && ( $1 != "serial" && $1 != "ethernet" && $1 != "audio" && $1 != "localhost" ) ]]; then
+    usageExit
+fi

Setting ADTPRO_HOME is obvious. Changing uname -p to uname -m is less obvious, until you note that uname -p returns unknown on many Linux installations, including the Raspberry Pi. I see you changed how headless is processed here—entirely so you could add the usage message? If so, I'll make the usage message work more the way the rest of the script does and submit that change to David for upstream inclusion.

The real meat follows:

 # For Linux, use this:
 if [ "$OS" = "Linux" ]; then
+
+    serialPortName=
+    if [[ $1 == "serial" ]]; then
+        if [[ $2 ]]; then
+            serialPortName="$2"
+            [[ ${serialPortName:0:5} == "/dev/" ]] && serialPortName=${serialPortName:5}
+            if [[ ! -c /dev/$serialPortName ]]; then
+                echo "Serial port $serialPortName not found." 1>&2
+                usageExit
+            fi
+        elif [[ -c /dev/ttyUSBlower ]]; then
+            serialPortName=ttyUSBlower
+        elif [[ $(ls -1 /dev/ttyUSBlower_hub* 2> /dev/null | wc -l) -gt 0 ]]; then
+            serialPortName=$(ls -1 /dev/ttyUSBlower_hub* 2> /dev/null | head -1 | cut -c 6-)
+        elif [[ $(ls -1 /dev/ttyUSBupper_hub* 2> /dev/null | wc -l) -gt 1 ]]; then
+            serialPortName=$(ls -1 /dev/ttyUSBupper_hub* 2> /dev/null | head -1 | cut -c 6-)
+        else
+            echo "No eligible USB-to-serial adapter found." 1>&2
+            echo "Possible ports:" 1>&2
+            echo " lower USB port"
+            echo " any port on lower USB hub with no other adapters"
+            echo " lowest port on USB hub on upper or lower USB port with multiple adapters"
+            usageExit
+        fi
+    fi
+
+    if [[ $(grep CommPort= /usr/local/adtpro/disks/ADTPro.properties) ]]; then
+        if [[ $serialPortName ]]; then
+            sed -i "s/^CommPort=.*$/CommPort=\/dev\/$serialPortName/" /usr/local/adtpro/disks/ADTPro.properties &> /dev/null
+        else
+            serialPortName=$(grep 'CommPort=/dev/' ADTPro.properties 2> /dev/null | cut -f 3 -d '/')
+        fi
+    else
+        echo -e "#ADTPro.properties\n#$(date)\nCommPortSpeed=115200\nCommPortBootstrapSpeed=2400\nCommPort=/dev/$serialPortName\nCommPortBootstrapPacing=250\nHardwareHandshaking=false\nSerialIPHost=localhost\nSerialIPPort=1977" > /usr/local/adtpro/disks/ADTPro.properties
+        chmod ugo+w /usr/local/adtpro/disks/ADTPro.properties
+    fi
+
+    ADTPRO_EXTRA_JAVA_PARMS="-Dgnu.io.rxtx.SerialPorts=/dev/$serialPortName"
+
   if [ -f /usr/bin/raspi-config ]; then
-    export RXTXLIB=lib/rxtx/%RXTX_VERSION%/arm
-    ADTPRO_EXTRA_JAVA_PARMS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyAMA0"
+        export RXTXLIB=lib/rxtx/rxtx-2.2pre2-local/arm
   elif [ "$OS_ARCH" = "i686" ]; then
-    export RXTXLIB=lib/rxtx/%RXTX_VERSION%/i686-pc-linux-gnu
+        export RXTXLIB=lib/rxtx/rxtx-2.2pre2-local/i686-pc-linux-gnu
   else
     if [ "$OS_ARCH" = "i386" ]; then
-      export RXTXLIB=lib/rxtx/%RXTX_VERSION%/i686-pc-linux-gnu
+            export RXTXLIB=lib/rxtx/rxtx-2.2pre2-local/i686-pc-linux-gnu
     else  
-      export RXTXLIB=lib/rxtx/%RXTX_VERSION%/x86_64-unknown-linux-gnu
+            export RXTXLIB=lib/rxtx/rxtx-2.2pre2-local/x86_64-unknown-linux-gnu
     fi
   fi
 fi

That's a big bite. There's a fair number of lines we can ignore due to the minus side being a script template. I note you try to force ONE serial port to be used here, and we've already discussed how the UDEV rules you've got now just won't quite do going forward. But I also think upstream does it wrong here by hard-coding ttyUSB0 and ttyAMA0 on the Pi. Probably the best solution all around is either a UDEV rule that does what /dev/serial SHOULD do (enumerate all serial devices, not just the USB ones), or to write some function that can build a list of serial devices. The trick there is that we'd probably prefer /dev/serial/by-path/ entries over /dev/tty* entries for those that have them.

Is there a reason you create the ADTPro properties file here instead of just running it? with serial and the port name to use in the environment?

Let's skip the OS X and Solaris stuff since that's just template related.

-if [ "$1x" = "headlessx" ]; then
-  shift
-  if [ "$1x" = "x" ] || [ ! -f /usr/bin/xvfb-run ]; then
-    if [ ! -f /usr/bin/xvfb-run ]; then
+if [[ $headless ]]; then
+    if [[ ! $1 || ! -f /usr/bin/xvfb-run ]]; then
+        if [[ ! -f /usr/bin/xvfb-run ]]; then
       echo "Headless operation requires xvfb."
+            usageExit
     else
-      echo "usage: adtpro.sh [ headless ] [ serial | ethernet | audio | localhost ]"
+            echo "Headless operation requires a communication mode (e.g. serial)."
+            usageExit
     fi
     exit 1
   else

There's the rest of the headless and other argument parsing getting moved around. I'd probably change those [[ ! -f /usr/bin/xvfb-run ]]'s to ! command -v xvfb-run >/dev/null. That's another one for upstream too.

@@ -75,5 +130,13 @@
   fi
 fi

+if [[ $serialPortName && $(ps aux | grep "/sbin/getty.*$serialPortName") ]]; then
+    sudo pkill -f "/sbin/getty.*$serialPortName"
+fi
+sudo pkill -f [A]DTPro
 cd "$ADTPRO_HOME"/disks
-$HEADLESS"$MY_JAVA_HOME"java -Xms256m -Xmx512m "$TWEAK" $ADTPRO_EXTRA_JAVA_PARMS -cp ../lib/%ADTPRO_VERSION%:../"$RXTXLIB"/../RXTXcomm.jar:../lib/AppleCommander/AppleCommander-%AC_VERSION%.jar org.adtpro.ADTPro $*
\ No newline at end of file
+$HEADLESS"$MY_JAVA_HOME"java -Xms256m -Xmx512m "$TWEAK" $ADTPRO_EXTRA_JAVA_PARMS -cp ../lib/ADTPro.jar:../"$RXTXLIB"/../RXTXcomm.jar:../lib/AppleCommander/AppleCommander-ac.jar org.adtpro.ADTPro $* &
+if [[ $1 == "serial" ]]; then
+    echo "Starting up on interface $serialPortName. Please wait..."
+fi
+sleep 30

What was the reason for the sleep 30 in there? I'm betting that's the reason why my Pi's boot process seems to halt an annoyingly long time vs. vanilla Raspbian. ;)

That bit there with disabling a getty that might be running on the serial port in question probably isn't real systemd compatible. Likely the ttyusbhandler also breaks it. That'll want to be a systemd service file most likely. Fortunately, it's actually pretty easy to write those so that you can configure what port causes stuff to happen and what to have happen, and make the whole thing contingent on there being enough system running to actually have the thing start.

Anyway, if there's anything you can add to all of that, lemme know!

Thanks! :)

[IvanExpert]

That's totally on me. :) I actually didn't check the scripts for bashisms, I just made them all use bash since most of the scripts did. Might wanna revert that for this script if it truly isn't necessary. Anyway…

Your call. Can't remember anything about that.
I see you changed how headless is processed here—entirely so you could add the usage message? If so, I'll make the usage message work more the way the rest of the script does and submit that change to David for upstream inclusion.
So, this is interesting -- there was no headless capability at all in stock ADTPro in version 1.2.7, which is what I based the script on, only a single parameter to specifiy starting up in a particular communication mode. It looks like after the release of A2CLOUD, Dave must have liked the headless capability and put a simplified version into the 1.2.9 startup script. So you could say that it's Dave who changed how headless is processed, although it may be that he simply copied however I did things in a much earlier iteration of A2CLOUD. (And, I do like clear usage messages.)
That's a big bite. There's a fair number of lines we can ignore due to the minus side being a script template. I note you try to force ONE serial port to be used here, and we've already discussed how the UDEV rules you've got now just won't quite do going forward.

Why won't UDEV rules do again, at leastl for Raspberry Pi? I don't want to throw the baby out with the bathwater, unless a better solution can be proposed.
But I also think upstream does it wrong here by hard-coding ttyUSB0 and ttyAMA0 on the Pi.

I'd agree. It looks like Dave also put that into the 1.2.9 script, based on an early version of A2CLOUD. That was how I used to do things before implementing the UDEV aliases. Early A2CLOUD was virtual drives only, no serial comm or Apple II Pi, so I figured one of those two would get the job done.
Probably the best solution all around is either a UDEV rule that does what /dev/serial SHOULD do (enumerate all serial devices, not just the USB ones), or to write some function that can build a list of serial devices. The trick there is that we'd probably prefer /dev/serial/by-path/ entries over /dev/tty* entries for those that have them.

The unsolveable problem, until you prove me otherwise, is that if you've got more than one USB-to-serial of the same chipset, as might be the case in a typical A2CLOUD setup, there is neither a) any way of distinguishing them from one another, nor b) predicting what names they're going to get in /dev/ if they're both present at startup. Hardcoding for actual known hardware ports, even if it's only for a specific hardware platform, is a better user experience, which is why I made the UDEV rules.

Also, ttyAMA0 is reserved for Apple II Pi, since that's what the Apple II Pi card uses, so I don't consider it any more; and it requires a boutique cable to pull up the 3.3v on the Pi to 5v.

Is there a reason you create the ADTPro properties file here instead of just running it? with serial and the port name to use in the environment?

Absolutely, but I can't remember exactly why. I think it's for the variable-specified serial port name off the bat. If you just run it, I think you get a default serial port, or no serial port, or you can't start up in the serial comm mode at the wanted comm rate, or something, and in any event something didn't work. It may also have been to provide the local IP capability in an early version of A2CLOUD. In other words, I remember something not working if I didn't do it this way, but I can't remember what.
There's the rest of the headless and other argument parsing getting moved around. I'd probably change those [[ ! -f /usr/bin/xvfb-run ]]'s to ! command -v xvfb-run >/dev/null. That's another one for upstream too.

Sure, why not. Again, keep in mind it's based off version 1.2.7, which has no headless or argument parsing at all.
+sleep 30
What was the reason for the sleep 30 in there? I'm betting that's the reason why my Pi's boot process seems to halt an annoyingly long time vs. vanilla Raspbian. ;)

So, I don't like it, but there's a reason for it, which unfortunately I'm also hazy about. Again, something didn't work well without it. It either has to do with making sure a new disk image is properly loaded, or flushed, or something; but I think it's because Java runs so slowly on the ARMv6 Pi's that it was a way of making sure that ADTPro server was actually running before the user tried to do anything. With the GUI you'd wait until you see the server window, and then wait some more to see the "serial" button become highlighted; but headless you can't do that, so this is the workaround to making sure it's initialized.

As for your startup delay, maybe, but I thought I worked around that so it could start up in the background. Maybe I didn't.

That bit there with disabling a getty that might be running on the serial port in question probably isn't real systemd compatible. Likely the ttyusbhandler also breaks it.

Surely.
That'll want to be a systemd service file most likely. Fortunately, it's actually pretty easy to write those so that you can configure what port causes stuff to happen and what to have happen, and make the whole thing contingent on there being enough system running to actually have the thing start.

That's all you, man. Make it so!

[knghtbrd]

On Thu, Nov 19, 2015 at 03:57:50AM -0800, IvanExpert wrote:

That's totally on me. :) I actually didn't check the scripts for bashisms, I just made them all use bash since most of the scripts did. Might wanna revert that for this script if it truly isn't necessary. Anyway…

Your call. Can't remember anything about that.

I'll give it a once over at least. Nothing there looks to be a
bashism and diff reduction is a good idea in genera.

I see you changed how headless is processed here—entirely so you could add the usage message? If so, I'll make the usage message work more the way the rest of the script does and submit that change to David for upstream inclusion.
So, this is interesting -- there was no headless capability at all in stock ADTPro in version 1.2.7, which is what I based the script on, only a single parameter to specifiy starting up in a particular communication mode. It looks like after the release of A2CLOUD, Dave must have liked the headless capability and put a simplified version into the 1.2.9 startup script. So you could say that it's Dave who changed how headless is processed, although it may be that he simply copied however I did things in a much earlier iteration of A2CLOUD. (And, I do like clear usage messages.)

Ah interesting! Well then, I think I will re-implement the clean
usage instructions on top of his version and submit that as a patch
upstream. Good to know that he's watching what we do for the Pi and
taking ideas from it.

That's a big bite. There's a fair number of lines we can ignore due to the minus side being a script template. I note you try to force ONE serial port to be used here, and we've already discussed how the UDEV rules you've got now just won't quite do going forward.

Why won't UDEV rules do again, at leastl for Raspberry Pi? I don't want to throw the baby out with the bathwater, unless a better solution can be proposed.

You can use udev rules, but the idea under systemd is that udev
triggers systemd which recognizes a service should be started for a
given port, and starts it.

I may actually write udev rules to create a better /dev/serial.
Theoretically /dev/serial exists to do what you did with the USBlower
and USBupper. My irritation with it is that it ONLY contains USB
serial devices! Mine looks like this:

/dev/serial
|-- by-id
| |-- usb-FTDI_USB_Serial_Converter_FT8ZQX5V-if00-port0 -> ../../ttyUSB3
| |-- usb-FTDI_USB_Serial_Converter_FTGUK9F7-if00-port0 -> ../../ttyUSB0
| |-- usb-Keyspan__a_division_of_InnoSys_Inc._Keyspan_USB_Serial_Adapter-if00-port0 -> ../../ttyUSB1
| -- usb-Keyspan__a_division_of_InnoSys_Inc._Keyspan_USB_Serial_Adapter-if00-port1 -> ../../ttyUSB2 -- by-path
|-- platform-3f980000.usb-usb-0:1.2:1.0-port0 -> ../../ttyUSB3
|-- platform-3f980000.usb-usb-0:1.4:1.0-port0 -> ../../ttyUSB0
|-- platform-3f980000.usb-usb-0:1.5:1.0-port0 -> ../../ttyUSB1
`-- platform-3f980000.usb-usb-0:1.5:1.0-port1 -> ../../ttyUSB2

2 directories, 8 files

In fact that tree illustrates the problem--ttyUSB3 is going to be
ttyUSB0 on my next reboot most likely. But it doesn't matter if I
had referred to it using either the by-id or by-path symlink.

Notably the two FTDI serial devices have some kind of serial number
thing there. I don't know where that comes from, but the absolutely
ridiculous Keyspan__a_divisiion_of_Stupid_Device_Naming_Inc. (which
is unsupported by default, see #14 for that), does not have one.

I think a device name like /dev/tty-serial/usb-0:1.2:1.0-port0 or
/dev/tty-serial/arm-gpio-uart-port0 or /dev/tty-serial/pc-port0 would
be quite descriptive. The USB numbering will be arbitrary to an end
user, but all they need to know is that once they identify it, that
will be its name as long as they don't go rearranging their USB
connections.

But I also think upstream does it wrong here by hard-coding ttyUSB0 and ttyAMA0 on the Pi.

I'd agree. It looks like Dave also put that into the 1.2.9 script, based on an early version of A2CLOUD. That was how I used to do things before implementing the UDEV aliases. Early A2CLOUD was virtual drives only, no serial comm or Apple II Pi, so I figured one of those two would get the job done.

Good to know that Dave got it from you. That means if I can come up
with something that's better, we can give him that instead. :)

Probably the best solution all around is either a UDEV rule that does what /dev/serial SHOULD do (enumerate all serial devices, not just the USB ones), or to write some function that can build a list of serial devices. The trick there is that we'd probably prefer /dev/serial/by-path/ entries over /dev/tty* entries for those that have them.

The unsolveable problem, until you prove me otherwise, is that if you've got more than one USB-to-serial of the same chipset, as might be the case in a typical A2CLOUD setup, there is neither a) any way of distinguishing them from one another, nor b) predicting what names they're going to get in /dev/ if they're both present at startup. Hardcoding for actual known hardware ports, even if it's only for a specific hardware platform, is a better user experience, which is why I made the UDEV rules.

Unfortunately you can't. You need some way to identify the device by
where it is connected and possibly by its manufacturer. I don't
dispute that in the least. But trying to physically describe the USB
port layout on three major versions of the Raspberry Pi, the five
versions of Banana Pi, the five ODROID boards, ARM-based ChromeOS
devices, and anything else that one might install Raspbian on ...

Basically Raspbian has become to armv6hf/armv7hf devices what Debian
is to pretty much everything else. It's not that creating symlinks
to ports using names that won't change is a bad idea. It's just that
we need more generic names, and to let the user tell us which one
he's connecting where. I have four USB-serial devices above. I'm
not likely to bother with ttyAMA0, for example.

I think the solution to that is some udev rules like the above along
with a config script that guides you through the process of assigning
your serial ports however you want them.

Also, ttyAMA0 is reserved for Apple II Pi, since that's what the Apple II Pi card uses, so I don't consider it any more; and it requires a boutique cable to pull up the 3.3v on the Pi to 5v.

But you might not have an Apple II Pi card. If you didn't get one
before, you can't currently get one now. A level shifter can be had
on eBay cheaply enough, but it's kinda fiddly to connect. If you're
using an actual serial port (SSC or port), you'd be just as happy
using another USB-serial device. It's less fiddly that way.

I'd rather not tie anyone into anything, though I agree ttyAMA0 is
the logical default for those who have the hardware. It just should
be possible to change it if you know the default is the wrong choice
in your case.

Is there a reason you create the ADTPro properties file here instead of just running it? with serial and the port name to use in the environment?

Absolutely, but I can't remember exactly why. I think it's for the variable-specified serial port name off the bat. If you just run it, I think you get a default serial port, or no serial port, or you can't start up in the serial comm mode at the wanted comm rate, or something, and in any event something didn't work. It may also have been to provide the local IP capability in an early version of A2CLOUD. In other words, I remember something not working if I didn't do it this way, but I can't remember what.

I can bet that I can guess what it is now:

You generally start it headless when the device is connected. But.
If you weren't starting it headless, if a port had not yet been
configured, the user would be expected to pick a port, verify the
speed and handshaking, etc, and then start listening on serial.

If this is the first time you've run ADTPro, it hasn't got those
defaults saved yet. So how can you start it running headless to use
serial port settings that haven't been selected yet?

I have a feeling at some point I'm producing a shell script that
duplicates the preference settings dialogs. Actually, if I could
also pass command line arguments to do bootstrapping, and could start
keeping track of the PID ... hmm. Some of this will definitely
require patching the java program a bit, but you might never need to
actually see the ADTPro interface. That's good if you actually don't
have a display connected to it.

+sleep 30
What was the reason for the sleep 30 in there? I'm betting that's the reason why my Pi's boot process seems to halt an annoyingly long time vs. vanilla Raspbian. ;)

So, I don't like it, but there's a reason for it, which unfortunately I'm also hazy about. Again, something didn't work well without it. It either has to do with making sure a new disk image is properly loaded, or flushed, or something; but I think it's because Java runs so slowly on the ARMv6 Pi's that it was a way of making sure that ADTPro server was actually running before the user tried to do anything. With the GUI you'd wait until you see the server window, and then wait some more to see the "serial" button become highlighted; but headless you can't do that, so this is the workaround to making sure it's initialized.

As for your startup delay, maybe, but I thought I worked around that so it could start up in the background. Maybe I didn't.

I'll just make it sleep only if stdout is a tty.

That bit there with disabling a getty that might be running on the serial port in question probably isn't real systemd compatible. Likely the ttyusbhandler also breaks it.

Surely.
That'll want to be a systemd service file most likely. Fortunately, it's actually pretty easy to write those so that you can configure what port causes stuff to happen and what to have happen, and make the whole thing contingent on there being enough system running to actually have the thing start.

That's all you, man. Make it so!

I'll see what I can come up with.

Joseph

[IvanExpert]

On Nov 19, 2015, at 6:59 PM, Joseph Carter [email protected] wrote:

On Thu, Nov 19, 2015 at 03:57:50AM -0800, IvanExpert wrote:

That's totally on me. :) I actually didn't check the scripts for bashisms, I just made them all use bash since most of the scripts did. Might wanna revert that for this script if it truly isn't necessary. Anyway…

Your call. Can't remember anything about that.

I'll give it a once over at least. Nothing there looks to be a
bashism and diff reduction is a good idea in genera.

I found at last one bashism: ${serialPortName:0:5}. I felt bash was ubiquitous enough that there was no reason to expect it. it. You may feel differently.

The unsolveable problem, until you prove me otherwise, is that if you've got more than one USB-to-serial of the same chipset, as might be the case in a typical A2CLOUD setup, there is neither a) any way of distinguishing them from one another, nor b) predicting what names they're going to get in /dev/ if they're both present at startup. Hardcoding for actual known hardware ports, even if it's only for a specific hardware platform, is a better user experience, which is why I made the UDEV rules.

Unfortunately you can't. You need some way to identify the device by
where it is connected and possibly by its manufacturer. I don't
dispute that in the least. But trying to physically describe the USB
port layout on three major versions of the Raspberry Pi, the five
versions of Banana Pi, the five ODROID boards, ARM-based ChromeOS
devices, and anything else that one might install Raspbian on ...

Basically Raspbian has become to armv6hf/armv7hf devices what Debian
is to pretty much everything else. It's not that creating symlinks
to ports using names that won't change is a bad idea. It's just that
we need more generic names, and to let the user tell us which one
he's connecting where. I have four USB-serial devices above. I'm
not likely to bother with ttyAMA0, for example.

I think the solution to that is some udev rules like the above along
with a config script that guides you through the process of assigning
your serial ports however you want them.

Ok, I see where you're going with this. I didn't realize Raspbian was used on other boards. I guess if there were some one-time user-friendly way of asking the user what adapter is what, and then remembering what port it's in and instructing the user to mark it or note it as well, that might be plausible.

Is there a reason you create the ADTPro properties file here instead of just running it? with serial and the port name to use in the environment?

I can bet that I can guess what it is now:

You generally start it headless when the device is connected. But.
If you weren't starting it headless, if a port had not yet been
configured, the user would be expected to pick a port, verify the
speed and handshaking, etc, and then start listening on serial.

If this is the first time you've run ADTPro, it hasn't got those
defaults saved yet. So how can you start it running headless to use
serial port settings that haven't been selected yet?

That sounds right.

I have a feeling at some point I'm producing a shell script that
duplicates the preference settings dialogs. Actually, if I could
also pass command line arguments to do bootstrapping, and could start
keeping track of the PID ... hmm. Some of this will definitely
require patching the java program a bit, but you might never need to
actually see the ADTPro interface. That's good if you actually don't
have a display connected to it.

It would definitely be a bonus to be able to trigger bootstrap from command line so the user theoretically never has to fuss with GUI.

+sleep 30

I'll just make it sleep only if stdout is a tty.

Good idea!

ID

[knghtbrd]

On Fri, Nov 20, 2015 at 05:38:23AM -0800, IvanExpert wrote:

I'll give it a once over at least. Nothing there looks to be a
bashism and diff reduction is a good idea in genera.

I found at last one bashism: ${serialPortName:0:5}. I felt bash was ubiquitous enough that there was no reason to expect it. it. You may feel differently.

As long as the script is labeled as using bash, I'm not concerned
about it. Debian at least includes dash as /bin/sh.

Unfortunately you can't. You need some way to identify the device by
where it is connected and possibly by its manufacturer. I don't
dispute that in the least. But trying to physically describe the USB
port layout on three major versions of the Raspberry Pi, the five
versions of Banana Pi, the five ODROID boards, ARM-based ChromeOS
devices, and anything else that one might install Raspbian on ...

Basically Raspbian has become to armv6hf/armv7hf devices what Debian
is to pretty much everything else. It's not that creating symlinks
to ports using names that won't change is a bad idea. It's just that
we need more generic names, and to let the user tell us which one
he's connecting where. I have four USB-serial devices above. I'm
not likely to bother with ttyAMA0, for example.

I think the solution to that is some udev rules like the above along
with a config script that guides you through the process of assigning
your serial ports however you want them.

Ok, I see where you're going with this. I didn't realize Raspbian was used on other boards. I guess if there were some one-time user-friendly way of asking the user what adapter is what, and then remembering what port it's in and instructing the user to mark it or note it as well, that might be plausible.

Yes, the ODROID-XU4 would make a very nice Raspple II buildbot
actually. It uses eMMC and has USB 3.0, so better storage is
available and a spinning platter is likely to last a lot longer with
the filesystem churn of a buildbot.

I have a feeling at some point I'm producing a shell script that
duplicates the preference settings dialogs. Actually, if I could
also pass command line arguments to do bootstrapping, and could start
keeping track of the PID ... hmm. Some of this will definitely
require patching the java program a bit, but you might never need to
actually see the ADTPro interface. That's good if you actually don't
have a display connected to it.

It would definitely be a bonus to be able to trigger bootstrap from command line so the user theoretically never has to fuss with GUI.

+sleep 30

I'll just make it sleep only if stdout is a tty.

Good idea!

Done as of 20815bf.

[knghtbrd]

I do believe this is pretty well resolved at this point--though see #30 for a problem with how ADTPro starts in that the headless X server seems not to be exiting when ADTPro does. This is very problematic on every Pi, but particularly on lower-spec models.