Package: httrack Version: 3.40.4-1 Severity: normal
when you use the command line, you expect to be able to ^C and ^Z with normal results, which in unix are normally to kill the program and suspend it, respectively. here are the results with httrack: $ httrack ... ^Z Moving into background to complete the mirror... [1]+ Stopped ... $ %1 httrack ... $ ps .... httrack ... httrack backgrounded itself when the user wanted it suspended, and did nothing when the user wanted it to be in the foreground. what i expected was a totally stopped process that can be foregrounded with fg. $ httrack ^C Quit program/Interrupt/Background/bLind background/Cancel? (Q/I/B/L/C) in other words, httrack asked a cryptic question when the user wanted it interrupted. there is no help or ? option. if you hit ^C again it seems to hang. if you then ^Z to get a prompt to kill it, you get the prompt, but killall does not work. in my case, kill -9 worked, but the process remained defunct. the calling process, a shell script, was backgrounded also, and had to be killed separately. i expected all httrack processes, including the parent shell script, to be completely killed. if not, i expected a question that could itself be ^Ced. it is necessary to do a ps occasionally to make sure httrack hasn't done something fancy and left itself running. as a result, httrack turns out to be a high maintenance program. surely not the implementor's intention. i don't know whether debian has standards for this, but i'm certain the ^Z behavior is far out of unix norms, and the ^C behavior is at least both very unusual and very buggy. if there is a standard, perhaps it mentions the quit signal (^\), which might be of some use, such as for doing what httrack wants to do with ^C. i don't know if httrack comes from the windows world, in which case maybe that is the reason. if so, thanks for porting to unix. would it be possible to complete the port by doing signals in a unix-like way? i wonder if this is related to python, since i have noticed bad signal behavior with bittorrent, bittornado, and cfv, all of which are written in python. i have noticed it occasionally with qtorrent, which seems to be written in python. i don't know if this pattern is cultural (e.g. python programmers believe that signals should be trapped and fancy processing done on them), incented (e.g. python by default does fancy signal processing), built in (e.g. python just has lots of signal-related bugs), due to complexity (e.g. python has complicated thread and signal code that incents bugs), a relic of the windows world, or coincidental. just reporting the observation. i would be very interested in knowing the answer, if anybody cares to provide it. thanks. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages httrack depends on: ii libc6 2.3.6-7 GNU C Library: Shared libraries ii libhttrack1 3.40.4-1 Httrack website copier library ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime httrack recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
