refdb-users — List for RefDB users

[Refdb-users] Question about Unicode

[Marc B. <ba...@sm...>]

Hi,

I am new to this list, and first of all I'd like to say that
RefDB is a great program with a lot of useful functions. On
the other side I must say, it was not so trivial to install =

on my Debian woody system, because several packages are not
"debianized" (eg libdbi - only available in an outdated version).

But now I have started to use it and .. already run into my
first problems. I have a reference with an author called H=F6=F6k,
and I wonder how to add this reference.

A RIS file with "H=F6=F6k" is rejected by addref, because of the two
umlauts (eg if I replace them with o, I can add the reference fine).
Now I edited the file in unicode mode and put the unicode equivalents
in. I now can at least add the reference. But if I look eg at a search
via the webinterface, I still get the ugly unicode raw code (H=C3=B6=C3=B6=
k).

I don't have much experience with unicode, so maybe I am doing something
stupid ?

How do people usually handle references with special characters ?

Thanks in advance,
  Marc Baaden

-- =

 Dr. Marc Baaden  - Institut de Biologie Physico-Chimique, Paris
 mailto:ba...@sm...      -      http://www.marc-baaden.de
 FAX: +49 697912 39550  -  Tel: +33 15841 5176 ou +33 609 843217

RE: [Refdb-users] RE: refdbc and php4

[Markus H. <mar...@mh...>]

QW5kIGhlcmUgZ29lcy4gSSd2ZSBjaGVja2VkIGluIGEgdmVyc2lvbiBvZiByZWZkYmMuYyB0aGF0
IGFwcGVhcnMgdG8NCndvcmsgdW5kZXIgdGhlIGZvbGxvd2luZyBjaXJjdW1zdGFuY2VzOg0KDQot
IGludGVyYWN0aXZlbHkNCi0gYmF0Y2ggbW9kZSwgZG9uJ3Qgc2VuZCBkYXRhIHRvIHN0ZGluDQot
IGJhdGNoIG1vZGUsIHNlbmQgZGF0YSB0byBzdGRpbg0KLSBidWlsdGluIENHSSBtb2RlDQotIGJh
dGNoIG1vZGUgY2FsbGVkIGZyb20gQ0dJIHBlcmwgc2NyaXB0LCBkb24ndCBzZW5kIGRhdGEgdG8g
c3RkaW4NCi0gYmF0Y2ggbW9kZSBjYWxsZWQgZnJvbSBDR0kgcGVybCBzY3JpcHQsIHNlbmQgZGF0
YSB0byBzdGRpbg0KDQpUaGlzIHdhcyB0ZXN0ZWQgd2l0aCBnZXRyZWYsIGJ1dCB0aGUgb3RoZXIg
YWZmZWN0ZWQgY29tbWFuZHMgc2hvdWxkDQp3b3JrIGFzIHdlbGwuIA0KDQpQbGVhc2UgdXNlIHRo
ZSBDVlMgdmVyc2lvbiAxLjQ3IGZvciB0ZXN0aW5nIHB1cnBvc2VzLCBvciBhcHBseSB0aGUNCmFw
cGVuZGVkIHBhdGNoIHRvIHRoZSB2ZXJzaW9uIG9mIHJlZmRiYy5jIHNoaXBwZWQgd2l0aCAwLjku
MS4NCg0KcmVnYXJkcywNCk1hcmt1cw0KDQpNYXJrdXMgSG9lbmlja2Egd3JpdGVzOg0KID4gSSdk
IGxpa2UgdG8gZml4IHRoaXMgcHJvYmxlbSB3aGlsZSBJJ20gYXQgaXQuIEl0IHdvbid0IHRha2Ug
bG9uZyB1bnRpbA0KID4gc29tZW9uZSBlbHNlIG5lZWRzIHRoaXMgZmVhdHVyZS4NCiA+IA0KDQo9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09DQpSQ1MgZmlsZTogL2N2c3Jvb3QvcmVmZGIvcmVmZGIvc3JjL3JlZmRiYy5jLHYN
CnJldHJpZXZpbmcgcmV2aXNpb24gMS40NA0KcmV0cmlldmluZyByZXZpc2lvbiAxLjQ3DQpkaWZm
IC11IC1yMS40NCAtcjEuNDcNCi0tLSByZWZkYi9yZWZkYi9zcmMvcmVmZGJjLmMJMjAwMy8wMS8w
NiAwMTowNzoxMQkxLjQ0DQorKysgcmVmZGIvcmVmZGIvc3JjL3JlZmRiYy5jCTIwMDMvMDIvMTUg
MjI6MzQ6NTYJMS40Nw0KQEAgLTEsNyArMSw3IEBADQogLyorKysrKysrKysrKysrKysrKw0KICAg
cmVmZGJjIC0gdGhlIHJlZmRiIGNsaWVudCBjb25zb2xlIGFwcGxpY2F0aW9uDQogICBtYXJrdXNA
bWhvZW5pY2thLmRlIDItMTAtMDANCi0gICRJZDogcmVmZGJjLmMsdiAxLjQ0IDIwMDMvMDEvMDYg
MDE6MDc6MTEgbWhvZW5pY2thIEV4cCAkDQorICAkSWQ6IHJlZmRiYy5jLHYgMS40NyAyMDAzLzAy
LzE1IDIyOjM0OjU2IG1ob2VuaWNrYSBFeHAgJA0KIA0KICAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVl
IHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQogICAgaXQg
dW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBhcyBwdWJs
aXNoZWQgYnkNCkBAIC0yOSw2ICsyOSw3IEBADQogI2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KICNp
bmNsdWRlIDxzeXMvZmlsZS5oPg0KICNpbmNsdWRlIDxzeXMvc3RhdC5oPg0KKyNpbmNsdWRlIDxz
eXMvaW9jdGwuaD4NCiANCiAjaW5jbHVkZSA8c3RkaW8uaD4NCiAjaW5jbHVkZSA8ZXJybm8uaD4N
CkBAIC0xOTMsNiArMTk0LDggQEANCiAgIGludCBuX29wdCwgaSwgajsNCiAgIGludCBuX3JlYWRp
bml0ID0gMTsgLyogaWYgMSwgcmVhZCBjb25maWcgZmlsZS4gSWYgMCwgc2tpcCBjb25maWcgZmls
ZSAqLw0KICAgaW50IHJldHZhbDsNCisgIGludCBuX3Rlc3RfY2dpID0gMTsgLyogd2hldGhlciB0
byB0ZXN0IGZvciBDR0kgZW52aXJvbm1lbnQgKi8NCisgIGludCBuX2luYnl0ZXMgPSAwOyAvKiBu
dW1iZXIgb2YgYnl0ZXMgdG8gYmUgcmVhZCBvbiBzdGRpbiAqLw0KICAgRklMRSogZXJyc3RyZWFt
Ow0KICNpZmRlZiBSRUZEQl9DR0kNCiAgIHN0cnVjdCBsaWxpZm9ybSBzZW50aW5lbDsNCkBAIC0y
MDQsOSArMjA3LDE4IEBADQogICAvKiBBbGxvdyBjb25kaXRpb25hbCBwYXJzaW5nIG9mIHRoZSB+
Ly5pbnB1dHJjIGZpbGUuICovDQogICBybF9yZWFkbGluZV9uYW1lID0gcmVhZGxpbmVfbmFtZTsN
CiANCi0gIC8qIHRlc3QgaG93IHdlIHdlcmUgaW52b2tlZCAqLw0KKyAgLyogbG9vayBmb3IgYmF0
Y2ggY29tbWFuZC4gSWYgZm91bmQsIGRvbid0IHRlc3QgZm9yIENHSSBlbnZpcm9ubWVudCAqLw0K
KyAgZm9yIChpID0gMDsgaSA8IGFyZ2M7IGkrKykgew0KKyAgICBpZiAoYXJndltpXVswXSA9PSAn
LScgJiYgYXJndltpXVsxXSA9PSAnQycpIHsNCisgICAgICBuX3Rlc3RfY2dpID0gMDsNCisgICAg
ICBicmVhazsNCisgICAgfQ0KKyAgfQ0KKw0KICNpZmRlZiBSRUZEQl9DR0kNCi0gIG5fY2dpID0g
aXNfY2dpKCZyZXF1ZXN0X21ldGhvZCwgJmNvbnRlbnRfbGVuZ3RoLCBkZWxheWVkX2NnaV9lcnJt
c2cpOyAvKiAxIGlmIHdlIGFyZSBydW5uaW5nIGFzIGEgY2dpIGFwcCAqLw0KKyAgaWYgKG5fdGVz
dF9jZ2kpIHsNCisgICAgbl9jZ2kgPSBpc19jZ2koJnJlcXVlc3RfbWV0aG9kLCAmY29udGVudF9s
ZW5ndGgsIGRlbGF5ZWRfY2dpX2Vycm1zZyk7IC8qIDEgaWYgd2UgYXJlIHJ1bm5pbmcgYXMgYSBj
Z2kgYXBwICovDQorICB9DQogI2VuZGlmDQogDQogICAvKiByZWRpcmVjdCBlcnJvciBtZXNzYWdl
cyBjb3JyZWN0bHkgKi8NCkBAIC0yMTcsMTAgKzIyOSwyMyBAQA0KICAgICBlcnJzdHJlYW0gPSBz
dGRlcnI7DQogICB9DQogDQotICBpZiAoIWlzYXR0eShmaWxlbm8oc3RkaW4pKSkgeyAvKiBpZiB3
ZSByZWNlaXZlIGRhdGEgb24gc3RkaW4gdmlhIGEgcmVkaXJlY3Rpb24gb3IgYSBwaXBlICovDQot
ICAgIG5fcmVhZF9zdGRpbiA9IDE7DQorICAvKiBzd2l0Y2ggb24gcmVhZGluZyBmcm9tIHN0ZGlu
IGlmIHdlIHJlY2VpdmUgZGF0YSBvbiBzdGRpbiB2aWEgYQ0KKyAgICAgcmVkaXJlY3Rpb24gb3Ig
YSBwaXBlLiAqLw0KKy8qICAgaWYgKCFpc2F0dHkoZmlsZW5vKHN0ZGluKSkgJiYgIW5fY2dpX2Vu
dikgeyAgKi8NCisvKiAgICAgbl9yZWFkX3N0ZGluID0gMTsgKi8NCisvKiAgIH0gKi8NCisjaWZk
ZWYgRklPTlJFQUQNCisgIGlmIChpb2N0bChmaWxlbm8oc3RkaW4pLCBGSU9OUkVBRCwgJm5faW5i
eXRlcykgIT0gLTEpIHsNCisgICAgaWYgKG5faW5ieXRlcyA+IDApIHsNCisgICAgICBuX3JlYWRf
c3RkaW4gPSAxOw0KKyAgICB9DQogICB9DQotICAgIA0KKyAgLyogZWxzZTogdGhlcmUgd2FzIGFu
IGVycm9yLCBhbmQgd2UgY2FuJ3Qgc2FmZWx5IGFzc3VtZSB0aGF0IHdlIGNhbg0KKyAgICAgcmVh
ZCBmcm9tIHN0ZGluICovDQorI2VuZGlmDQorICAvKiBlbHNlOiBpZiBGSU9OUkVBRCBpcyBub3Qg
c3VwcG9ydGVkLCBjb21tYW5kcyB0aGF0IGFjY2VwdCBpbnB1dA0KKyAgICAgZnJvbSBzdGRpbiBt
dXN0IGJlIGNhbGxlZCB3aXRoIHRoZSAnLWYgc3RkaW4nIHN3aXRjaCAqLw0KKw0KICAgaWYgKCh0
aGVfY29tbWFuZCA9IChjaGFyKiltYWxsb2ModGhlX2NvbW1hbmRfbGVuKSkgPT0gTlVMTCkgew0K
ICAgICB3cml0ZV9lcnIoIm91dCBvZiBtZW1vcnlcbiIpOw0KICAgICBleGl0ICgxKTsNCkBAIC00
NzMsNyArNDk4LDcgQEANCiAgIH0NCiANCiAgIC8qIG5vdyByZXBvcnQgaW5jb3JyZWN0IGNnaSBp
bnB1dCwgaWYgYW55ICovDQotICBpZiAoZGVsYXllZF9jZ2lfZXJybXNnWzBdKSB7DQorICBpZiAo
ZGVsYXllZF9jZ2lfZXJybXNnWzBdICYmIG5fY2dpKSB7DQogICAgIExPR19QUklOVChMT0dfRVJS
LCBkZWxheWVkX2NnaV9lcnJtc2cpOw0KICAgICBleGl0KDEpOw0KICAgfQ0KQEAgLTk1NSwxMiAr
OTgwLDE3IEBADQogCWJyZWFrOw0KICAgICAgIGNhc2UgJ2YnOg0KIAkvKiAgICAgICAgcHJpbnRm
KCItZiAlc1xuIiwgb3B0YXJnKTsgKi8NCi0JaW5maWxlID0gY2Fub25pY2FsaXplX3BhdGgob3B0
YXJnKTsNCi0JaWYgKGluc2VydF9saWxpbWVtKCZzZW50aW5lbCwgKHZvaWQqKikmaW5maWxlLCBO
VUxMKSkgew0KLQkgIGRlbGV0ZV9hbGxfbGlsaW1lbSgmc2VudGluZWwpOw0KLQkgIHJldHVybiAx
Ow0KKwlpZiAoIXN0cmNtcChvcHRhcmcsICJzdGRpbiIpKSB7DQorCSAgbl9yZWFkX3N0ZGluID0g
MTsNCisJfQ0KKwllbHNlIHsNCisJICBpbmZpbGUgPSBjYW5vbmljYWxpemVfcGF0aChvcHRhcmcp
Ow0KKwkgIGlmIChpbnNlcnRfbGlsaW1lbSgmc2VudGluZWwsICh2b2lkKiopJmluZmlsZSwgTlVM
TCkpIHsNCisJICAgIGRlbGV0ZV9hbGxfbGlsaW1lbSgmc2VudGluZWwpOw0KKwkgICAgcmV0dXJu
IDE7DQorCSAgfQ0KKwkgIG5fcmVhZF9maWxlID0gMTsNCiAJfQ0KLQluX3JlYWRfZmlsZSA9IDE7
DQogCWJyZWFrOw0KICAgICAgIGNhc2UgJ2gnOg0KIAlwcmludGYoIkRlbGV0ZXMgdGhlIHNwZWNp
ZmllZCByZWZlcmVuY2VzIGZyb20gdGhlIGRhdGFiYXNlXG5TeW50YXg6IGRlbGV0ZXJlZiBbLWMg
Y29tbWFuZF0gWy1kIGRhdGFiYXNlXSBbLWhdIFstbyBvdXRmaWxlXSBbLU8gb3V0ZmlsZV0ge0lE
fC1mIGluZmlsZX1cbk9wdGlvbnM6IC1jIGNvbW1hbmQgICBwaXBlIHRoZSBvdXRwdXQgdGhyb3Vn
aCBjb21tYW5kXG4gICAgICAgICAtZCBkYXRhYmFzZSAgc3BlY2lmeSB0aGUgZGF0YWJhc2UgdG8g
d29yayB3aXRoXG4gICAgICAgICAtZiBpbmZpbGUgICAgUmVhZCB0aGUgcmVmZXJlbmNlIElEcyBm
cm9tIGZpbGUgaW5maWxlXG4gICAgICAgICAtaCAgICAgICAgICAgcHJpbnRzIHRoaXMgbWluaS1o
ZWxwXG4gICAgICAgICAtbyBvdXRmaWxlICAgc2F2ZSB0aGUgb3V0cHV0IGluIG91dGZpbGUgKG92
ZXJ3cml0ZSlcbiAgICAgICAgIC1PIG91dGZpbGUgICBhcHBlbmQgdGhlIG91dHB1dCB0byBvdXRm
aWxlXG4gICAgICAgICBBbGwgb3RoZXIgYXJndW1lbnRzIGFyZSBpbnRlcnByZXRlZCBhcyBJRHMg
dG8gZGVsZXRlLlxuIik7DQpAQCAtMTMxOSwxMiArMTM0OSwxNyBAQA0KIAlicmVhazsNCiAgICAg
ICBjYXNlICdmJzoNCiAJLyogICAgICAgIHByaW50ZigiLWYgJXNcbiIsIG9wdGFyZyk7ICovDQot
CWluZmlsZSA9IGNhbm9uaWNhbGl6ZV9wYXRoKG9wdGFyZyk7DQotCWlmIChpbnNlcnRfbGlsaW1l
bSgmc2VudGluZWwsICh2b2lkKiopJmluZmlsZSwgTlVMTCkpIHsNCi0JICBkZWxldGVfYWxsX2xp
bGltZW0oJnNlbnRpbmVsKTsNCi0JICByZXR1cm4gMTsNCisJaWYgKCFzdHJjbXAob3B0YXJnLCAi
c3RkaW4iKSkgew0KKwkgIG5fcmVhZF9zdGRpbiA9IDE7DQorCX0NCisJZWxzZSB7DQorCSAgaW5m
aWxlID0gY2Fub25pY2FsaXplX3BhdGgob3B0YXJnKTsNCisJICBpZiAoaW5zZXJ0X2xpbGltZW0o
JnNlbnRpbmVsLCAodm9pZCoqKSZpbmZpbGUsIE5VTEwpKSB7DQorCSAgICBkZWxldGVfYWxsX2xp
bGltZW0oJnNlbnRpbmVsKTsNCisJICAgIHJldHVybiAxOw0KKwkgIH0NCisJICBuX3JlYWRfZmls
ZSA9IDE7DQogCX0NCi0Jbl9yZWFkX2ZpbGUgPSAxOw0KIAlicmVhazsNCiAgICAgICBjYXNlICdo
JzoNCiAJZnByaW50ZihlcnJzdHJlYW0sICJBZGRzIG9yIHJlbW92ZXMgdGhlIHNwZWNpZmllZCBy
ZWZlcmVuY2VzIGZyb20geW91ciBwZXJzb25hbCBpbnRlcmVzdCBsaXN0XG5TeW50YXg6IHBpY2ty
ZWYgWy1jIGNvbW1hbmRdIFstZCBkYXRhYmFzZV0gWy1oXSBbLXJdIHtJRHwtZiBpbmZpbGV9XG5P
cHRpb25zOiAtYyBjb21tYW5kICAgcGlwZSB0aGUgb3V0cHV0IHRocm91Z2ggY29tbWFuZFxuICAg
ICAgICAgLWQgZGF0YWJhc2UgIHNwZWNpZnkgdGhlIGRhdGFiYXNlIHRvIHdvcmsgd2l0aFxuICAg
ICAgICAgLWYgaW5maWxlICAgIFJlYWQgdGhlIHJlZmVyZW5jZSBJRHMgZnJvbSBmaWxlIGluZmls
ZVxuICAgICAgICAgLWggICAgICAgICAgIHByaW50cyB0aGlzIG1pbmktaGVscFxuICAgICAgICAg
LW8gb3V0ZmlsZSAgIHNhdmUgdGhlIG91dHB1dCBpbiB0aGUgZmlsZSBvdXRmaWxlIChvdmVyd3Jp
dGUpXG4gICAgICAgICAtTyBvdXRmaWxlICAgYXBwZW5kIHRoZSBvdXRwdXQgdG8gdGhlIGZpbGUg
b3V0ZmlsZVxuICAgICAgICAgLXIgICAgICAgICAgIHJlbW92ZSBmcm9tIHBlcnNvbmFsIGludGVy
ZXN0IGxpc3QgKGRlZmF1bHQgaXMgYWRkKVxuICAgICAgICAgQWxsIG90aGVyIGFyZ3VtZW50cyBh
cmUgaW50ZXJwcmV0ZWQgYXMgSURzIHRvIHBpY2sgb3IgdG8gcmVtb3ZlLlxuIik7DQpAQCAtMTky
OCwxMiArMTk2MywxNyBAQA0KIAlicmVhazsNCiAgICAgICBjYXNlICdmJzoNCiAJLyogICAgICAg
IHByaW50ZigiLWYgJXNcbiIsIG9wdGFyZyk7ICovDQotCWluZmlsZSA9IGNhbm9uaWNhbGl6ZV9w
YXRoKG9wdGFyZyk7DQotCWlmIChpbnNlcnRfbGlsaW1lbSgmc2VudGluZWwsICh2b2lkKiopJmlu
ZmlsZSwgTlVMTCkpIHsNCi0JICBkZWxldGVfYWxsX2xpbGltZW0oJnNlbnRpbmVsKTsNCi0JICBy
ZXR1cm4gMTsNCisJaWYgKCFzdHJjbXAob3B0YXJnLCAic3RkaW4iKSkgew0KKwkgIG5fcmVhZF9z
dGRpbiA9IDE7DQorCX0NCisJZWxzZSB7DQorCSAgaW5maWxlID0gY2Fub25pY2FsaXplX3BhdGgo
b3B0YXJnKTsNCisJICBpZiAoaW5zZXJ0X2xpbGltZW0oJnNlbnRpbmVsLCAodm9pZCoqKSZpbmZp
bGUsIE5VTEwpKSB7DQorCSAgICBkZWxldGVfYWxsX2xpbGltZW0oJnNlbnRpbmVsKTsNCisJICAg
IHJldHVybiAxOw0KKwkgIH0NCisJICBuX3JlYWRfZmlsZSA9IDE7DQogCX0NCi0Jbl9yZWFkX2Zp
bGUgPSAxOw0KIAlicmVhazsNCiAgICAgICBjYXNlICdoJzoNCiAJcHJpbnRmKCJEaXNwbGF5cyB0
aGUgcmVzdWx0IG9mIGEgZGF0YWJhc2Ugc2VhcmNoLlxuU3ludGF4OiBnZXRyZWYgIFstYyBjb21t
YW5kXSBbLWQgZGF0YWJhc2VdIFstaF0gWy1vIG91dGZpbGVdIFstTyBvdXRmaWxlXVstUF0gWy1S
IHBkZnJvb3RdIFstcyBmb3JtYXRdIFstUyB0YWddIFstdCBvdXRwdXQtZm9ybWF0XSB7c2VhcmNo
LXN0cmluZ3wtZiBpbmZpbGV9XG5TZWFyY2gtc3RyaW5nOiB7OlhZOns8fD18IT18Pn17dW5peC1y
ZWdleHB9fSBbQU5EfE9SfEFORCBOT1RdIFsuLi5dXG53aGVyZSBYWSBzcGVjaWZpZXMgdGhlIGZp
ZWxkIHRvIHNlYXJjaCBpblxuT3B0aW9uczogLWMgY29tbWFuZCAgIHBpcGUgdGhlIG91dHB1dCB0
aHJvdWdoIGNvbW1hbmRcbiAgICAgICAgIC1kIGRhdGFiYXNlICBzcGVjaWZ5IHRoZSBkYXRhYmFz
ZSB0byB3b3JrIHdpdGhcbiAgICAgICAgIC1oICAgICAgICAgICBwcmludHMgdGhpcyBtaW5pLWhl
bHBcbiAgICAgICAgIC1vIG91dGZpbGUgICBzYXZlIHRoZSBvdXRwdXQgaW4gb3V0ZmlsZSAob3Zl
cndyaXRlKVxuICAgICAgICAgLU8gb3V0ZmlsZSAgIGFwcGVuZCB0aGUgb3V0cHV0IHRvIG91dGZp
bGVcbiAgICAgICAgIC1QICAgICAgICAgICBsaW1pdCBzZWFyY2ggdG8gcGVyc29uYWwgaW50ZXJl
c3QgbGlzdFxuICAgICAgICAgLVIgICAgICAgICAgIHVzZSBwZGZyb290IGFzIHJvb3QgZm9yIHBh
dGggb2YgcGRmIGZpbGVzXG4gICAgICAgICAtcyBmb3JtYXQgICAgc3BlY2lmeSBmaWVsZHMgZm9y
IHNjcmVlbiBvciBzdHlsZSBmb3IgRG9jQm9vayBvdXRwdXRcbiAgICAgICAgIC1TIHRhZyAgICAg
ICBzb3J0IG91dHB1dCBieSB0YWcgSUQgKGRlZmF1bHQpIG9yIFBZXG4gICAgICAgICAtdCBvdXRw
dXQtZm9ybWF0IGRpc3BsYXkgYXMgZm9ybWF0IHNjcm4sIGh0bWwsIGRiMzEsIHRlaXgsIHJpcywg
b3IgYmlidGV4XG4gICAgICAgICAtZiBpbmZpbGUgICAgdXNlIHRoZSBzYXZlZCBzZWFyY2ggbGlu
ZSBpbiBmaWxlIGluZmlsZVxuICAgICAgICAgQWxsIG90aGVyIGFyZ3VtZW50cyBhcmUgaW50ZXJw
cmV0ZWQgYXMgdGhlIHNlYXJjaCBzdHJpbmcuXG4iKTsNCkBAIC0yMDczLDEwICsyMTEzLDIzIEBA
DQogCS8qICAgICAgcHJpbnRmKCIlZFxuIiwgb3B0aW5kKTsgKi8NCiAJZm9yIChpID0gb3B0aW5k
OyBpIDwgaW5hcmdjOyBpKyspIHsNCiAJICBzdHJjYXQoc2x2YWxzLm91dGJ1ZmZlciwgaW5hcmd2
W2ldKTsNCi0JICBzdHJjYXQoc2x2YWxzLm91dGJ1ZmZlciwgIiAiKTsNCisJICAvKiB0aGUgdG9r
ZW5pemVyIHJldHVybnMgYSBxdW90ZWQgaXRlbSBhcyBhIHNlcGFyYXRlIHRva2VuDQorCSAgICAg
ZXZlbiBpZiB0aGVyZSBpcyBubyBzcGFjZSBiZXR3ZWVuIGUuZy4gYSAnPScgYW5kIHRoZQ0KKwkg
ICAgIHF1b3RlZCBpdGVtLiBUbyByZWN0aWZ5IHRoaXMsIGNoZWNrIHdoZXRoZXIgdGhlIHByZXZp
b3VzDQorCSAgICAgaXRlbSBlbmRlZCB3aXRoIGEgJz0nICovDQorCSAgaWYgKHNsdmFscy5vdXRi
dWZmZXJbc3RybGVuKHNsdmFscy5vdXRidWZmZXIpLTFdICE9ICc9Jykgew0KKwkgICAgc3RyY2F0
KHNsdmFscy5vdXRidWZmZXIsICIgIik7DQorCSAgfQ0KIAl9DQogCXN0cmNweSgmc2x2YWxzLm91
dGJ1ZmZlcltzdHJsZW4oc2x2YWxzLm91dGJ1ZmZlciktMV0sICJcIiIpOyAvKiByZW1vdmUgdHJh
aWxpbmcgc3BhY2UgKi8NCiAgICAgICB9DQorICAgIH0NCisgIH0NCisNCisgIC8qIG1ha2Ugc3Vy
ZSB0aGVyZSdzIG5vIG5ld2xpbmVzIGluIHRoZSBzdHJpbmc7IHJldXNlIHJlYWRfcmVzdWx0ICov
DQorICBmb3IgKHJlYWRfcmVzdWx0ID0gc2x2YWxzLm91dGJ1ZmZlcjsgKnJlYWRfcmVzdWx0OyBy
ZWFkX3Jlc3VsdCsrKSB7DQorICAgIGlmICgqcmVhZF9yZXN1bHQgPT0gJ1xuJyB8fCAqcmVhZF9y
ZXN1bHQgPT0gJ1xyJykgew0KKyAgICAgICpyZWFkX3Jlc3VsdCA9ICcgJzsNCiAgICAgfQ0KICAg
fQ0KIA0KDQotLSANCk1hcmt1cyBIb2VuaWNrYQ0KbWFya3VzLmhvZW5pY2thQGNhdHMuZGUNCihT
cGFtLXByb3RlY3RlZCBlbWFpbDogcmVwbGFjZSB0aGUgcXVhZHJ1cGVkcyB3aXRoICJtaG9lbmlj
a2EiKQ0KaHR0cDovL3d3dy5taG9lbmlja2EuZGU=

RE: [Refdb-users] RE: refdbc and php4

[Markus H. <mar...@mh...>]

Alan Anderson writes:
 > I'm OK with this, but I wonder if there isn't a more elegant solution.  How do common programs
 > handle it?  For example, grep, cat, head, tail, etc. all seem to work in all situations.  Can you
 > model what they do?

They use calls like ioctl(fd, FIONREAD, &numbytes) to find out about
the number of bytes waiting to be read. This is unfortunately not
portable. Last time I tried Cygwin didn't implement this particular
ioctl call due to inherent limitations in the Win32 API so this
wouldn't work on a fairly popular platform. Unfortunately ioctl
doesn't return an error on Cygwin in this case but crashes right away,
so there's no way to find out at runtime whether this is going to
work. I could test at compile time whether FIONREAD is defined, though
(I hope it isn't defined in Cygwin when the call doesn't work
anyway). In this case, you could rely on the automatic check on all
platforms that support this ioctl call, but '-f stdin' would be
mandatory on Cygwin and maybe some other obscure platforms.

 > 
 > FYI, I don't think this is critical to what I'm doing, so unless someone else is interested in this
 > functionality, it may not be worth the effort.

I'd like to fix this problem while I'm at it. It won't take long until
someone else needs this feature.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] RE: refdbc and php4

[Alan A. <al...@ru...>]

Markus,

Thanks for the reply.

> Actually I tried to catch this problem at the very beginning in the
> program so that it should automatically propagate to everything
> else. I don't have the slightest idea why this change would affect
> listdb.

Afraid I'm not much help here, it was just an observation.  When I copied back the old (my modified)
version, the listdb worked again.  I'll try to look at it a little more next week.  I guess I would
assume the test for n_cgi_env would need to be done for each command, but I didn't look to see if
you had done it.


> This is indeed a consequence of the patch. I'm afraid I'll have to go
> back to A1 and start all over. All this autodetection stuff seems to
> be crappy in some way.
>
> Would it be acceptable to allow '-f stdin' as an option for the
> deleteref, pickref, addref, and getref commands? All of them currently
> support reading from a file by using '-f filename'. This way I could
> get rid of these futile attempts to automagically detect whether
> there's data at stdin.

I'm OK with this, but I wonder if there isn't a more elegant solution.  How do common programs
handle it?  For example, grep, cat, head, tail, etc. all seem to work in all situations.  Can you
model what they do?

FYI, I don't think this is critical to what I'm doing, so unless someone else is interested in this
functionality, it may not be worth the effort.

Later,

Al

[Refdb-users] RE: refdbc and php4

[Markus H. <mar...@mh...>]

Hi Alan,

al...@ru... writes:
 > Markus,
 > 
 > I got a chance to try your two patches.  They appear to work for the case of
 > addref/getref.  However, my "Change DB" page fails because the listdb command
 > did not work.  I'm guessing the test for n_cgi_env didn't get propagated to that
 > routine yet.  Note also, that I have NOT tried updateref or deleteref, but then
 > I'm guessing you hadn't made a complete pass through the source since you
 > weren't sure the fix would work.

Actually I tried to catch this problem at the very beginning in the
program so that it should automatically propagate to everything
else. I don't have the slightest idea why this change would affect
listdb.

 > 
 > I did think of another potential problem based on your fix.  What if my CGI app
 > wants to pipe input to refdbc?  Does this change preclude us from using
 > redirection?  I took a couple minutes to try it, and I couldn't get it to work,
 > but it is possible there was something else wrong.  Rather than providing a
 > filename to the addref command, I piped the output from cat into it, and this
 > failed, although my return value was apparently not indicating an error.  E.g.,
 > 
 >    my $result = `$refdbc -C "addref $tmpfile";
 > 
 > changed to 
 > 
 >    my $result = `cat $tmpfile | $refdbc -C "addref";
 > 
 > It worked on the commandline, but when I tried it from the CGI script, it did
 > NOT return an error, but the record was never added.  A quick glance at the log
 > file didn't really indicate anything because the addref entry didn't show a file
 > name (as expected since it was redirected).
 > 

This is indeed a consequence of the patch. I'm afraid I'll have to go
back to A1 and start all over. All this autodetection stuff seems to
be crappy in some way.

Would it be acceptable to allow '-f stdin' as an option for the
deleteref, pickref, addref, and getref commands? All of them currently
support reading from a file by using '-f filename'. This way I could
get rid of these futile attempts to automagically detect whether
there's data at stdin.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-users] RE: refdbc and php4

[<al...@ru...>]

Markus,

I got a chance to try your two patches.  They appear to work for the case of
addref/getref.  However, my "Change DB" page fails because the listdb command
did not work.  I'm guessing the test for n_cgi_env didn't get propagated to that
routine yet.  Note also, that I have NOT tried updateref or deleteref, but then
I'm guessing you hadn't made a complete pass through the source since you
weren't sure the fix would work.

I did think of another potential problem based on your fix.  What if my CGI app
wants to pipe input to refdbc?  Does this change preclude us from using
redirection?  I took a couple minutes to try it, and I couldn't get it to work,
but it is possible there was something else wrong.  Rather than providing a
filename to the addref command, I piped the output from cat into it, and this
failed, although my return value was apparently not indicating an error.  E.g.,

   my $result = `$refdbc -C "addref $tmpfile";

changed to 

   my $result = `cat $tmpfile | $refdbc -C "addref";

It worked on the commandline, but when I tried it from the CGI script, it did
NOT return an error, but the record was never added.  A quick glance at the log
file didn't really indicate anything because the addref entry didn't show a file
name (as expected since it was redirected).

Anyway, I don't see this as a hurdle for me because I don't think I'll need to
redirect anything, but I thought you'd find it interesting.

Hope this helps,

Al



-------------------------------------------------
This mail sent by http://webmail.rushmore.com

RE: [Refdb-users] refdbc and php4

[<al...@ru...>]

Markus,

Thanks for the diff.

Yes, I only experienced difficulties when running as CGI script.  Although I
can't say I really tried it as a non-CGI script.  

Later,

Al

Quoting Markus Hoenicka <mar...@mh...>:

> Hi Alan,
> 
> please find the diff attached below.
> 
> I gather from the example script that you sent that this was also a
> CGI script. I wasn't aware of that, and maybe this makes a difference,
> as I ran my test script from the command line. I'll run some more
> tests and we'll see.
> 
> regards,
> Markus
> 
> diff -c -r1.44 -r1.45
> *** refdb/refdb/src/refdbc.c	2003/01/06 01:07:11	1.44
> --- refdb/refdb/src/refdbc.c	2003/02/06 22:12:46	1.45
> ***************
> *** 1,7 ****
>   /*+++++++++++++++++
>     refdbc - the refdb client console application
>     ma...@mh... 2-10-00
> !   $Id: refdbc.c,v 1.44 2003/01/06 01:07:11 mhoenicka Exp $
>   
>      This program is free software; you can redistribute it and/or modify
>      it under the terms of the GNU General Public License as published by
> --- 1,7 ----
>   /*+++++++++++++++++
>     refdbc - the refdb client console application
>     ma...@mh... 2-10-00
> !   $Id: refdbc.c,v 1.45 2003/02/06 22:12:46 mhoenicka Exp $
>   
>      This program is free software; you can redistribute it and/or modify
>      it under the terms of the GNU General Public License as published by
> ***************
> *** 207,212 ****
> --- 207,222 ----
>     /* test how we were invoked */
>   #ifdef REFDB_CGI
>     n_cgi = is_cgi(&request_method, &content_length, delayed_cgi_errmsg); /*
> 1 if we are running as a cgi app */
> + 
> +   /* look for batch command. If found, set n_cgi to 0 because we are
> +    apparently invoked as a regular app by a CGI app */
> +   for (i = 0; i < argc; i++) {
> +     if (argv[i][0] == '-' && argv[i][1] == 'C') {
> +       n_cgi = 0;
> +       break;
> +     }
> +   }
> + 
>   #endif
>   
>     /* redirect error messages correctly */
> 
> -- 
> Markus Hoenicka
> mar...@ca...
> (Spam-protected email: replace the quadrupeds with "mhoenicka")
> http://www.mhoenicka.de
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Refdb-users mailing list
> Ref...@li...
> https://lists.sourceforge.net/lists/listinfo/refdb-users
> 
> 




-------------------------------------------------
This mail sent by http://webmail.rushmore.com

RE: [Refdb-users] refdbc and php4

[Markus H. <mar...@mh...>]

Alan,

could you please test the following patch in addition to the one I
sent previously? Let me know whether it fixes your problem.

Markus Hoenicka writes:
 > Hi Alan,
 > 
 > I just found out that it indeed makes a difference. When I run my test
 > script as a CGI app, it reports that stdin is not connected to a
 > tty. Under these circumstances, refdbc will try to read from stdin and
 > fail with the messages that you reported. I'll try and see whether
 > there is a clean fix for this problem.

diff -c -r1.45 refdbc.c
*** refdbc.c	6 Feb 2003 22:12:46 -0000	1.45
--- refdbc.c	12 Feb 2003 22:57:11 -0000
***************
*** 193,198 ****
--- 193,199 ----
    int n_opt, i, j;
    int n_readinit = 1; /* if 1, read config file. If 0, skip config file */
    int retval;
+   int n_cgi_env = 0; /* will be 1 if started in a CGI environment */
    FILE* errstream;
  #ifdef REFDB_CGI
    struct liliform sentinel;
***************
*** 207,212 ****
--- 208,214 ----
    /* test how we were invoked */
  #ifdef REFDB_CGI
    n_cgi = is_cgi(&request_method, &content_length, delayed_cgi_errmsg); /* 1 if we are running as a cgi app */
+   n_cgi_env = n_cgi;
  
    /* look for batch command. If found, set n_cgi to 0 because we are
     apparently invoked as a regular app by a CGI app */
***************
*** 227,233 ****
      errstream = stderr;
    }
  
!   if (!isatty(fileno(stdin))) { /* if we receive data on stdin via a redirection or a pipe */
      n_read_stdin = 1;
    }
      
--- 229,239 ----
      errstream = stderr;
    }
  
!   /* switch on reading from stdin if we receive data on stdin via a
!      redirection or a pipe. If refdbc is started from a CGI app as a
!      regular app, it will still think that stdin is not connected to a
!      tty. In that case we must not try to read from stdin */
!   if (!isatty(fileno(stdin)) && !n_cgi_env) { 
      n_read_stdin = 1;
    }
      

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] refdbc and php4

[Markus H. <mar...@mh...>]

Hi Alan,

I just found out that it indeed makes a difference. When I run my test
script as a CGI app, it reports that stdin is not connected to a
tty. Under these circumstances, refdbc will try to read from stdin and
fail with the messages that you reported. I'll try and see whether
there is a clean fix for this problem.

regards,
Markus

Markus Hoenicka writes:
 > I gather from the example script that you sent that this was also a
 > CGI script. I wasn't aware of that, and maybe this makes a difference,
 > as I ran my test script from the command line. I'll run some more
 > tests and we'll see.

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] refdbc and php4

[Markus H. <mar...@mh...>]

Hi Alan,

please find the diff attached below.

I gather from the example script that you sent that this was also a
CGI script. I wasn't aware of that, and maybe this makes a difference,
as I ran my test script from the command line. I'll run some more
tests and we'll see.

regards,
Markus

diff -c -r1.44 -r1.45
*** refdb/refdb/src/refdbc.c	2003/01/06 01:07:11	1.44
--- refdb/refdb/src/refdbc.c	2003/02/06 22:12:46	1.45
***************
*** 1,7 ****
  /*+++++++++++++++++
    refdbc - the refdb client console application
    ma...@mh... 2-10-00
!   $Id: refdbc.c,v 1.44 2003/01/06 01:07:11 mhoenicka Exp $
  
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
--- 1,7 ----
  /*+++++++++++++++++
    refdbc - the refdb client console application
    ma...@mh... 2-10-00
!   $Id: refdbc.c,v 1.45 2003/02/06 22:12:46 mhoenicka Exp $
  
     This program is free software; you can redistribute it and/or modify
     it under the terms of the GNU General Public License as published by
***************
*** 207,212 ****
--- 207,222 ----
    /* test how we were invoked */
  #ifdef REFDB_CGI
    n_cgi = is_cgi(&request_method, &content_length, delayed_cgi_errmsg); /* 1 if we are running as a cgi app */
+ 
+   /* look for batch command. If found, set n_cgi to 0 because we are
+    apparently invoked as a regular app by a CGI app */
+   for (i = 0; i < argc; i++) {
+     if (argv[i][0] == '-' && argv[i][1] == 'C') {
+       n_cgi = 0;
+       break;
+     }
+   }
+ 
  #endif
  
    /* redirect error messages correctly */

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] refdbc and php4

[<al...@ru...>]

The example you show is pretty much as I remember my initial attempts.  I've
attached a file (refdbc-test.pl) which is one of the initial files I used. 
You'll notice that I use "refdbc-nocgi," so you'll need to change that line.

I've also attached two other files (refdbcgi.pl and RefDB_CGI.pm) which make up
the application I started.  Much of the functionality is presented, but not
functional.  You can add references using the forms, and you should be able to
submit a query and get results, but you cannot modify records and the query
results are probably not that pretty--I got distracted with "real" work this
week and last.  To run this application you'll need a few Perl Modules,
specifically CGI::Application, HTML::Templates, and (indirectly) CGI.  Beyond
that you should only need to modify the one line which specifies the refdb
executable and place the two files in a directory with executable permissions
within your webserver's file space.

Can you attach a patch for the changes which keep refdbc out of CGI mode with
the  -C option?  If I get the time, I'll look at how it works on my system.

Hope this helps,

Al


Quoting Markus Hoenicka <mar...@mh...>:

> Hi Alan & Howard,
> 
> I've been revisiting the problem of running refdbc from Perl or PHP
> today and ran into a small calamity: I can't reproduce the second
> problem Alan was mentioning, namely the fact that refdbc calls fgets
> and fails. What I did so far is to apply the first fix Alan
> suggested. refdbc now will not go into CGI mode if the -C command line
> option is present. I did not add the other suggested fixes (i.e. the
> tests for n_batchmode) as they would break some refdbc functionality.
> 
> If I then run the following Perl script:
> 
> ---8<---
> #!/usr/bin/perl -w
> 
> system "/home/markus/prog/refdb/src/refdbc -d pseudotest -C getref :ID:=1 -c
> stdout";
> ---8<---
> 
> it works just fine, whereas it should fail with dubious error messages
> according to your posts. Could you please provide an example of a call
> that fails, or maybe an example Perl script that reproduces the problem?
> 
> BTW I've used a small test program to verify my hypothesis that the
> following check:
> 
> if (!isatty(fileno(stdin))) {
>    /* read from stdin */
> ...
> }
> 
> is responsible for the problem you reported. Turns out that this call
> still reports that stdin is connected to a tty even if the program is
> called from a Perl script, so my assumption was wrong. Now I'm stymied
> as to why fgets would ever be called when refdbc is run from a script.
> 
> regards,
> Markus
> 
> Markus Hoenicka writes:
>  >  > The second problem is that refdbc attempts to call fgets in several
> places regardless of whether it
>  >  > is run in "batch" mode.  Attached is a diff file which should show you
> where fixes are needed, but
>  >  > you'll have to fight through some garbage changes that I made for
> debugging.  In two or three places
>  >  > there is a test like
>  >  > 
>  >  > 	if (n_read_file || n_read_stdin) {
>  >  > 
>  >  > If this test succeeds, then fgets is called (not directly, but
> eventually in each case--I'm not
>  >  > exactly sure what difficulty this causes, but I'm guessing the web
> server hasn't provided STDOUT or
>  >  > something--in any case, the fgets fails).  If the test fails, then the
> string sent to the refdbd
>  >  > server is not completed and you get the "unknown command" error in the
> log.  I changed these lines
>  >  > to also test for batch mode:
>  >  > 
>  >  > 	if ((n_read_file || n_read_stdin) && !n_batchmode) {
>  >  > 
>  >  > In this case, it does not call fgets AND the command string is
> correctly created and sent to refdbd.
>  >  > 
>  > 
>  > I'm not sure whether this is the correct fix. Both the com_pickref()
>  > and the com_deleteref() functions accept a list of ID values
>  > (e.g. from a previous getref -s ID call) on either stdin (in batch
>  > mode) or with the -f command line option (interactive mode). Your
>  > suggested fix would preclude the former use. I think we run into
>  > trouble right here:
>  > 
>  >   if (!isatty(fileno(stdin))) { /* if we receive data on stdin via a
> redirection or a pipe */
>  >     n_read_stdin = 1;
>  >   }
>  > 
>  > If a CGI app runs refdbc, stdin won't be a tty, and refdbc incorrectly
>  > assumes that data are waiting at stdin. I'm afraid I'll need another
>  > command line switch to keep refdbc from reading stdin when it's not
>  > supposed to.
>  > 
> 
> -- 
> Markus Hoenicka
> mar...@ca...
> (Spam-protected email: replace the quadrupeds with "mhoenicka")
> http://www.mhoenicka.de
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Refdb-users mailing list
> Ref...@li...
> https://lists.sourceforge.net/lists/listinfo/refdb-users
> 
> 




-------------------------------------------------
This mail sent by http://webmail.rushmore.com

RE: [Refdb-users] refdbc and php4

[Markus H. <mar...@mh...>]

Hi Alan & Howard,

I've been revisiting the problem of running refdbc from Perl or PHP
today and ran into a small calamity: I can't reproduce the second
problem Alan was mentioning, namely the fact that refdbc calls fgets
and fails. What I did so far is to apply the first fix Alan
suggested. refdbc now will not go into CGI mode if the -C command line
option is present. I did not add the other suggested fixes (i.e. the
tests for n_batchmode) as they would break some refdbc functionality.

If I then run the following Perl script:

---8<---
#!/usr/bin/perl -w

system "/home/markus/prog/refdb/src/refdbc -d pseudotest -C getref :ID:=1 -c stdout";
---8<---

it works just fine, whereas it should fail with dubious error messages
according to your posts. Could you please provide an example of a call
that fails, or maybe an example Perl script that reproduces the problem?

BTW I've used a small test program to verify my hypothesis that the
following check:

if (!isatty(fileno(stdin))) {
   /* read from stdin */
...
}

is responsible for the problem you reported. Turns out that this call
still reports that stdin is connected to a tty even if the program is
called from a Perl script, so my assumption was wrong. Now I'm stymied
as to why fgets would ever be called when refdbc is run from a script.

regards,
Markus

Markus Hoenicka writes:
 >  > The second problem is that refdbc attempts to call fgets in several places regardless of whether it
 >  > is run in "batch" mode.  Attached is a diff file which should show you where fixes are needed, but
 >  > you'll have to fight through some garbage changes that I made for debugging.  In two or three places
 >  > there is a test like
 >  > 
 >  > 	if (n_read_file || n_read_stdin) {
 >  > 
 >  > If this test succeeds, then fgets is called (not directly, but eventually in each case--I'm not
 >  > exactly sure what difficulty this causes, but I'm guessing the web server hasn't provided STDOUT or
 >  > something--in any case, the fgets fails).  If the test fails, then the string sent to the refdbd
 >  > server is not completed and you get the "unknown command" error in the log.  I changed these lines
 >  > to also test for batch mode:
 >  > 
 >  > 	if ((n_read_file || n_read_stdin) && !n_batchmode) {
 >  > 
 >  > In this case, it does not call fgets AND the command string is correctly created and sent to refdbd.
 >  > 
 > 
 > I'm not sure whether this is the correct fix. Both the com_pickref()
 > and the com_deleteref() functions accept a list of ID values
 > (e.g. from a previous getref -s ID call) on either stdin (in batch
 > mode) or with the -f command line option (interactive mode). Your
 > suggested fix would preclude the former use. I think we run into
 > trouble right here:
 > 
 >   if (!isatty(fileno(stdin))) { /* if we receive data on stdin via a redirection or a pipe */
 >     n_read_stdin = 1;
 >   }
 > 
 > If a CGI app runs refdbc, stdin won't be a tty, and refdbc incorrectly
 > assumes that data are waiting at stdin. I'm afraid I'll need another
 > command line switch to keep refdbc from reading stdin when it's not
 > supposed to.
 > 

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Markus H. <mar...@mh...>]

Bruce D'Arcus writes:
 > Interesting.  The logic here is: while it may take some work to create 
 > the RIS DTD, it'd be quicker than the combination of a) finishing up 
 > BibX, AND b) rewriting RefDB to support it?
 > 

Definitely. I don't want to appear too bold, but creating a DTD to
encode RIS datasets sounds like a weekend project. Adding BibX support
(including the formatting stuff) sounds like months of hard work. Keep
in mind that RIS is a *lot* simpler than BibX.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-users] refdbc and PHP

[Howard S. <hs...@uk...>]

Bruce D'Arcus asked for some details about the GUI I am
writing for refdbc. We have a project here in G=F6ttingen that needs a=20
central literature reference database -- enter RefDB.  However, there
are a couple of problems integrating it into the web site we are
building:

1) the GUI should fit consistently into the rest of the site

2) access should be restricted to certain groups of members of
     the project.

3) There are internal pages that are password
    protected.  The members don't want to enter a password
    more than once to access the internal web services, of
    which RefDB is only one.

For these reasons, I am building my own Web-GUI to RefDB.
(I should say to PART of RefDB, since it is a pretty versatile
system.) This lets me restrict what functions I offer the
users and check their input, etc. It also gives me a way to integrate
RefDB with other services, such as linking references to
specific projects.

This is the plan.  If anyone is interested in my code, they
are welcome to it, but be warned: it is very much in development
and messy, and there isn't very much of it yet.  In addition,
it has the hooks for the rest of the web site which might make
some of it a bit obscure.

I can offer:

1) the query mask and list pages
2) add new reference page

Yours,

-- Howard

--------------------------------------------------------------------
Dipl.-Phys. Howard Schultens                    Tel: +49 551 39-5914
Zentrum Physiologie                             FAX: +49 551 39-5923
Humboldtallee 23
37073 Goettingen      mailto:howard at ukps.gwdg.de
Germany               http://www.neuro-physiol.med.uni-goettingen.de
--------------------------------------------------------------------
 >>
 >>
 >> Bruce D'Arcus wrote:

 >>
 >>>
 >>>
 >>>Can you tell us a bit more about this GUI Howard?  Am curious!
 >>>
 >>>Bruce

Re: [Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Bruce D'A. <bd...@fa...>]

On Sunday, February 2, 2003, at 04:35  PM, Markus Hoenicka wrote:

> For short-term results a XML DTD based on RIS could be used, whereas 
> on the long run bibx would be the obvious choice.

Interesting.  The logic here is: while it may take some work to create 
the RIS DTD, it'd be quicker than the combination of a) finishing up 
BibX, AND b) rewriting RefDB to support it?

In any case, the sooner you have XML support for the raw data, the 
better.

Bruce

Re: [Refdb-users] GUI design?

[Bruce D'A. <bd...@fa...>]

On Saturday, February 1, 2003, at 11:45  PM, Alan Anderson wrote:

>> Or a perhaps more important example: a reference that is not covered 
>> by
>> existing types.  In the second example, you could set up a custom
>> template to represent that, while still using the existing RIS data
>> model.
>
> Couldn't this get confusing if you are using a type, eg. CONF, for 
> both conference proceeding and
> something not yet defined as a RIS type?  If records exist for both 
> types a user (and certainly a
> "poorly" designed program) could be confused by the results of a 
> query.  Is there an "unknown" or
> "general" type in RIS?

Part of the background to my question is discussions on BibX 
development, in which people like me --who come from the social 
sciences/humanities -- have been looking to be able to support 
references that existing tools (which tend to be rooted in the hard 
sciences) don't support too well.  There will always be references not 
covered well by a standardized data model, and so some method to 
customize reference types through a template system is desirable.  At 
least, this is what I am thinking.  It does open potential for misuse, 
but it seems to me that's countered by the greater clarity and 
repeatability of such an approach.

Part of the question is also motivated by a belief that as BibX gets 
closer to being finished, there ought to some way for different 
projects that might try to implement a data entry UI for it might 
collaborate.  Whether you are dealing with a web page, or a typical GUI 
app, the basic design will likely be the same (or should be).

Bruce

RE: [Refdb-users] GUI design?

[Markus H. <mar...@mh...>]

Alan Anderson writes:
 > "poorly" designed program) could be confused by the results of a query.  Is there an "unknown" or
 > "general" type in RIS?

Yes, it is called "GEN". Commercial applications make no assumptions
about which fields are used in this type. The bibliographic styles
usually dump all available information that is relevant to a
bibliography, i.e. everything except things like ID, notes, abstract
etc.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Markus H. <mar...@mh...>]

Alan Anderson writes:
 > I am aware of this.  My observation was that if refdbc selected HTML or CGI (I don't think this is
 > advertised as a type) as the type of data to be returned for a request, the HTML returned was a

CGI output is automatically selected whenever refdbc thinks it runs as
a CGI app (it wasn't always right about this as I've learned). I
didn't think anyone might want to request CGI output manually.

 > This was one of my ideas actually.  I thought about adding a backend for "segmented" HTML, so that
 > the client received the data formatted in HTML, but didn't get the header, footer, etc.  My other
 > idea was that maybe refdbd should only send/receive XML, and leave the formatting to the client.
 > After all, it is the client that is deciding the final output, so why should the server (refdbd)
 > need to know anything about what the client intends to do with the data.  This, obviously, would
 > require drastic changes in the design of Refdb, and I'm not willing to suggest that.  For now, I
 > think simply parsing the RIS should be sufficient.  If it isn't, you'll be the first to hear about
 > it. ;)

Well, actually there's nothing wrong about having it both ways. Why
shouldn't we add a XML backend that returns the full information like
the RIS backend does (keep in mind that the DocBook and TEI backends
return only a part of the information due to the limitations in the
DTDs). This information would be available to any custom client that
human ingenuity might develop, whereas the other backends would supply
the information to the current "dumb" clients (the clients are dumb on
purpose to make porting as simple as possible). For short-term results
a XML DTD based on RIS could be used, whereas on the long run bibx
would be the obvious choice.

I've been pondering a Perl module that implements the client/server
communication for the client side. This would allow rapid development
of custom clients using Perl. Using XML data for this purpose would
come in handy I think.

 > Give me a few more days, and I should have something a little more presentable.  But, I'll gladly
 > share what I have.
 > 

Sounds good to me!

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] GUI design?

[Alan A. <al...@ru...>]

Bruce,

> I've raised this question in another context, but since it seems people
> are working on improved GUI clients for RefDB, I'll raise it here:
>
> How are you guys designing the entry forms?  It seems to me there are
> two possible approaches:
>
> 1)  Just a straight representation of RIS (and in the future BibX).
>
> 2)  Introduce an abstraction, such that you have reference type
> specific field names that map onto the underling data model.
>
> To understand the difference, say you want to enter a movie.  In the
> first, you would use a field called "author" to enter the director.  In
> the second, you'd use a field called "director."  This would be
> particularly important for things like legal citations and such.

What I've done is a simple abstraction.  The form creation is customizable (although you'll need to
edit the Perl at this time) and one specifies the RIS field and a textual description used on the
form.  One can specify as many or as few fields as desired and the order they are displayed in the
form.  My intention was to avoid requiring an understanding of RIS for the users.  The important
example for me is a conference proceeding.  The user needs to specify a title for the paper, a
conference title, authors for the paper and editors for the conference proceedings.  I always forget
whether the editors are A2 or A3, so I wanted a way to set this one time and not have to worry about
it again.  The customization simply states that A3 is to be displayed as "Editor(s)", so the user
never even knows that what is entered relates to RIS.  Hopefully, they'll never have to know what
RIS is unless they need to do something speciallized.


> Or a perhaps more important example: a reference that is not covered by
> existing types.  In the second example, you could set up a custom
> template to represent that, while still using the existing RIS data
> model.

Couldn't this get confusing if you are using a type, eg. CONF, for both conference proceeding and
something not yet defined as a RIS type?  If records exist for both types a user (and certainly a
"poorly" designed program) could be confused by the results of a query.  Is there an "unknown" or
"general" type in RIS?


> The first is easier to program, the second probably more intuitive and
> flexible from a user standpoint (and is also how Endnote and other
> commercial products work).

I might argue whether the second is harder to program.  As an OOP believer, I see this as a typical
use of polymorphism.  One defines an abstract interface for data retrieval from the form, and each
type simply needs to follow the defined interface, but is allowed to present it to the user in
whatever way they see fit.  I'm not really using an OOP environment, so this doesn't apply to my
Perl GUI attempt, but if I were to attempt this from Java or C++ (and possibly PHP), I certainly
would take this approach.  My two cents worth...

Thanks for the input.

Al

RE: [Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Alan A. <al...@ru...>]

Markus,

>-------------- clip ---------------------------
> RefDB allows a limited amount of customization in that it uses
> header/footer templates for the CGI output. You can customize those
> without fiddling with the RefDB code itself. I'm afraid this is not
> sufficient for your purposes, but I'd like to point this out anyway.

I am aware of this.  My observation was that if refdbc selected HTML or CGI (I don't think this is
advertised as a type) as the type of data to be returned for a request, the HTML returned was a
complete page, header, title, and all.  This is fine for simple cases, but if the client wants
something other than simple HTML, say XHTML or the latest and greatest HTML variant, or in my case
simply the requested data formatted in HTML (without header, footer, etc.), this isn't currently
possible.

> You should also keep in mind that refdbd uses a fairly simple internal
> API to implement custom backends. If parsing the RIS output should be
> cumbersome, it would be fairly easy to clone the RIS backend and have
> it send back the data in whatever format you prefer.

This was one of my ideas actually.  I thought about adding a backend for "segmented" HTML, so that
the client received the data formatted in HTML, but didn't get the header, footer, etc.  My other
idea was that maybe refdbd should only send/receive XML, and leave the formatting to the client.
After all, it is the client that is deciding the final output, so why should the server (refdbd)
need to know anything about what the client intends to do with the data.  This, obviously, would
require drastic changes in the design of Refdb, and I'm not willing to suggest that.  For now, I
think simply parsing the RIS should be sufficient.  If it isn't, you'll be the first to hear about
it. ;)

> I'd be happy to see your results. Anything GUI will be greatly
> appreciated.

Give me a few more days, and I should have something a little more presentable.  But, I'll gladly
share what I have.

Al

[Refdb-users] GUI design?

[Bruce D'A. <bd...@fa...>]

I've raised this question in another context, but since it seems people 
are working on improved GUI clients for RefDB, I'll raise it here:

How are you guys designing the entry forms?  It seems to me there are 
two possible approaches:

1)  Just a straight representation of RIS (and in the future BibX).

2)  Introduce an abstraction, such that you have reference type 
specific field names that map onto the underling data model.

To understand the difference, say you want to enter a movie.  In the 
first, you would use a field called "author" to enter the director.  In 
the second, you'd use a field called "director."  This would be 
particularly important for things like legal citations and such.

Or a perhaps more important example: a reference that is not covered by 
existing types.  In the second example, you could set up a custom 
template to represent that, while still using the existing RIS data 
model.

The first is easier to program, the second probably more intuitive and 
flexible from a user standpoint (and is also how Endnote and other 
commercial products work).

Any thoughts on this?

Bruce

RE: [Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Markus H. <mar...@mh...>]

Alan Anderson writes:
 > My biggest hurdle is that refdbc/refdbd both provide HTML output, but it is the ENTIRE page, not
 > just the information of interest.  The philosophy I took was to send and receive RIS to/from refdbc,
 > and let the CGI app handle the formatting and display (my OOP background encourages me to prefer
 > separation of data and display).
 > 

RefDB allows a limited amount of customization in that it uses
header/footer templates for the CGI output. You can customize those
without fiddling with the RefDB code itself. I'm afraid this is not
sufficient for your purposes, but I'd like to point this out anyway.

You should also keep in mind that refdbd uses a fairly simple internal
API to implement custom backends. If parsing the RIS output should be
cumbersome, it would be fairly easy to clone the RIS backend and have
it send back the data in whatever format you prefer.

 > Best of luck with your GUI.  I look forward to seeing it.  Hopefully, I'll have something to share
 > soon also (I could probably share what I have if you, or anyone else, is interested).
 > 

I'd be happy to see your results. Anything GUI will be greatly
appreciated.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Markus H. <mar...@mh...>]

Howard Schultens writes:
 > would always work correctly from the command line. Alan's
 > patches fixed it, I can open a pipe to refdbc and get the
 > output.

Yes I know. After I read Alan's thoughts it was pretty clear to me why
it failed. It wasn't apparent to me initially that PHP runs as a CGI
app itself.

 > Actually, the command line interface is not that bad.  I'm making
 > good progress on a custom GUI using PHP. The
 > regular expression commands in PHP are pretty efficient for
 > separating the output.
 > 
 > I should say that the command line interface is OK on a Linux/UNIX
 > system.  I can't say anything about Windows.
 > 

I'm a lot into command line interfaces, but I realize that many others
are not. Especially Mac users seem oblivious to the existence of
command line interfaces, so I'd like to have a GUI in addition to
that. As I'm not a GUI programmer myself, I'd be thrilled to see what
you'll come up with. Is your PHP code custom tailored or is it going
to be useful for the general public?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

RE: [Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Alan A. <al...@ru...>]

Howard,

>--------------------clip-----------------------------------
> > I'd be glad if RefDB could be convinced to cooperate with PHP. This
> > would allow to build a nice user interface, much better than the crude
> > CGI stuff we've got now
>
> Actually, the command line interface is not that bad.  I'm making
> good progress on a custom GUI using PHP. The
> regular expression commands in PHP are pretty efficient for
> separating the output.

I'd be interested in hearing how far along you are on the PHP interface.  The reason I was faced
with the same problems was I started making a Perl script to emulate/replace the CGI support in
refdbc.  I wanted to be able to specify a file along with a reference and have it automatically
uploaded, placed in the repository, and the reference updated to reflect the existence of the file.
My original attempt was a simple form which simply took the ID and a file, but within a few hours I
was able to recreate most of the current CGI interface.  I've also added forms for inserting several
types of records without requiring a solid knowledge of RIS, and the code is flexible enough to
allow customization of these forms.  I'm working on the query interface now.

My biggest hurdle is that refdbc/refdbd both provide HTML output, but it is the ENTIRE page, not
just the information of interest.  The philosophy I took was to send and receive RIS to/from refdbc,
and let the CGI app handle the formatting and display (my OOP background encourages me to prefer
separation of data and display).


> I should say that the command line interface is OK on a Linux/UNIX
> system.  I can't say anything about Windows.

I initially struggled with the command-line interface because I really wanted something easy to use
(i.e. GUI), but like you I eventually found the command-line interface reasonably easy.  However,
outside of myself, there isn't anyone here that would be willing to use the database if only the
command-line interface was available.

Best of luck with your GUI.  I look forward to seeing it.  Hopefully, I'll have something to share
soon also (I could probably share what I have if you, or anyone else, is interested).

Al

[Refdb-users] Re: Refdb-users digest, Vol 1 #79 - 3 msgs

[Howard S. <ho...@uk...>]

Hi Markus,

ref...@li... wrote:
> 
> Message: 1
> From: "Markus Hoenicka" <mar...@mh...>
> Date: Wed, 29 Jan 2003 22:22:59 +0100
> To: ref...@li...
> Subject: [Refdb-users] refdbc and php4
> 
> Hi,
> 
> I have to admit that my PHP knowledge doesn't get me any further than
> creating my (static) personal website. I've never tried using RefDB
> from PHP.
> 
> Anyway, there's a few thoughts:
> 
> - there might be a quoting issue when running commands from PHP that
>   contain quoted arguments. Do the PHP docs mention anything like
>   this?
> 
> - Does PHP cause refdbc to run under an account that is not allowed to
>   read the global config file?
> 
> - What happens if you pass all configuration parameters on the refdbc
>   command line in your PHP code?

I tried all this, quoting and unquoting the arguments and
using the PHP functions 'escapeshellarg' and 'escapeshellcmd'
in various combinations -- it didn't work using PHP, but it
would always work correctly from the command line. Alan's
patches fixed it, I can open a pipe to refdbc and get the
output.

> 
> I'd be glad if RefDB could be convinced to cooperate with PHP. This
> would allow to build a nice user interface, much better than the crude
> CGI stuff we've got now

Actually, the command line interface is not that bad.  I'm making
good progress on a custom GUI using PHP. The
regular expression commands in PHP are pretty efficient for
separating the output.

I should say that the command line interface is OK on a Linux/UNIX
system.  I can't say anything about Windows.

Yours,

-- Howard
--------------------------------------------------------------------
Dipl.-Phys. Howard Schultens                    Tel: +49 551 39-5914
Zentrum Physiologie                             FAX: +49 551 39-5923
Humboldtallee 23
37073 Goettingen      mailto:howard at ukps.gwdg.de
Germany               http://www.neuro-physiol.med.uni-goettingen.de
--------------------------------------------------------------------