Discussion:
Need to pass ASCII-GS thru to lynxcgi: QUERY_STRING
Mark Dewhirst
2014-09-30 00:16:53 UTC
Permalink
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
David Woolley
2014-09-30 06:48:26 UTC
Permalink
Post by Mark Dewhirst
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!
That's correct. It should be provided as a % escape. Are you saying
that the equipment needs an illegal URI?
Ian Collier
2014-09-30 15:15:55 UTC
Permalink
Post by Mark Dewhirst
The embedded sub-field-terminator is always rendered by the RF-gun as
ASCII-GS (Group Separator, 0x1d, 035)
That ASCII control character is being silently suppressed from the
input, and I need a way to allow it to come through
If you add this line to lynx.cfg does it help?

KEYMAP:^]::CHAR

imc

Loading...