Mark Dewhirst
2014-09-30 00:16:53 UTC
Hi All,
Background....
We have found an unusual niche for lynx:- our warehouse management
system employs "RF-guns" (small screen WiFi units with barcode
scanners, see Intermec CK70 etc )
There are hundreds of units on the market, and to be able to use them
all, we run the RF-gun's telnet equivalent program and then run lynx
inside that.
The various screens needed by our application are HTML pages (almost
exclusively "forms") that are generated by a cluster of cgi-bins usually
accessed via 'lynxcgi:'
These RF-guns cause their laser-scanners to act like key-strokes.
So when the user scans a barcode, the data is pumped into the current
field on a form, and the cgi-bin eventually sees this as a classic
"QUERY_STRING=" environment variable.
My problem....
Most barcodes are a single field.... supermarket-product-code etc.
no issue. one-scan-to-one-form-field... easy! Even QR scans.
However there is a class of barcodes that contain sub-fields, and
some of those sub-fields are allowed to be of variable length.
The embedded sub-field-terminator is always rendered by the RF-gun as
ASCII-GS (Group Separator, 0x1d, 035) (see GS1 specification and
CODE-128 symbology... nicest web-site is www.adams1.com, if you have a
spare few days!!)
That ASCII control character is being silently suppressed from the
input, and I need a way to allow it to come through to the
QUERY_STRING. Actual display of the code-point is (from my point of
view) optional!
help!
Cheers
Mark ;-)
PS.. our current version is 2-8-7 across many platforms, but 85% are
now Linux (RedHat)...
Happy to update, especially if the character gymnastics are changed.
tools>
tools> r
file *lynx*
isislynx.hp.hpux: PA-RISC1.1 shared executable dynamically linked -
not stripped
isislynx.intel.linux: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not
stripped
isislynx.intel.linux64: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18,
not stripped
isislynx.intel.solaris: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), not stripped
isislynx.risc.aix: executable (RISC System/6000 V3.1) or obj module not
stripped
isislynx.sparc.solaris: ELF 32-bit MSB executable, SPARC, version 1 (SYSV),
dynamically linked (uses shared libs), not stripped
tools>
tools>
Mark Dewhirst | Development Manager | Microlistics
Email: <mailto:***@microlistics.com.au>
***@microlistics.com.au
Mobile: +61 419 306 940
Phone: +61 3 9326 7422
Website: <http://www.microlistics.com.au/> www.microlistics.com.au
microlistics_2013
Background....
We have found an unusual niche for lynx:- our warehouse management
system employs "RF-guns" (small screen WiFi units with barcode
scanners, see Intermec CK70 etc )
There are hundreds of units on the market, and to be able to use them
all, we run the RF-gun's telnet equivalent program and then run lynx
inside that.
The various screens needed by our application are HTML pages (almost
exclusively "forms") that are generated by a cluster of cgi-bins usually
accessed via 'lynxcgi:'
These RF-guns cause their laser-scanners to act like key-strokes.
So when the user scans a barcode, the data is pumped into the current
field on a form, and the cgi-bin eventually sees this as a classic
"QUERY_STRING=" environment variable.
My problem....
Most barcodes are a single field.... supermarket-product-code etc.
no issue. one-scan-to-one-form-field... easy! Even QR scans.
However there is a class of barcodes that contain sub-fields, and
some of those sub-fields are allowed to be of variable length.
The embedded sub-field-terminator is always rendered by the RF-gun as
ASCII-GS (Group Separator, 0x1d, 035) (see GS1 specification and
CODE-128 symbology... nicest web-site is www.adams1.com, if you have a
spare few days!!)
That ASCII control character is being silently suppressed from the
input, and I need a way to allow it to come through to the
QUERY_STRING. Actual display of the code-point is (from my point of
view) optional!
help!
Cheers
Mark ;-)
PS.. our current version is 2-8-7 across many platforms, but 85% are
now Linux (RedHat)...
Happy to update, especially if the character gymnastics are changed.
tools>
tools> r
file *lynx*
isislynx.hp.hpux: PA-RISC1.1 shared executable dynamically linked -
not stripped
isislynx.intel.linux: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not
stripped
isislynx.intel.linux64: ELF 64-bit LSB executable, x86-64, version 1
(GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18,
not stripped
isislynx.intel.solaris: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), dynamically linked (uses shared libs), not stripped
isislynx.risc.aix: executable (RISC System/6000 V3.1) or obj module not
stripped
isislynx.sparc.solaris: ELF 32-bit MSB executable, SPARC, version 1 (SYSV),
dynamically linked (uses shared libs), not stripped
tools>
tools>
Mark Dewhirst | Development Manager | Microlistics
Email: <mailto:***@microlistics.com.au>
***@microlistics.com.au
Mobile: +61 419 306 940
Phone: +61 3 9326 7422
Website: <http://www.microlistics.com.au/> www.microlistics.com.au
microlistics_2013