First and foremost, thanks everyone for such diligent and detailed work; also thanks for the interest in zshdb and contacting me about this.
In theory, I suppose it is possible to make this work, but in practice I don't see much of a point of it here. Some debuggers do support the notion of remote debugging -- in that situation there need not be an interactive tty. zsh has the primitives to support remote debugging (I think). But it's not something I want to undertake; if someone else were interested in this enough to work on it I'd help them out. Also it is possible to segregate tests into those that require tty's and those don't. For example test/unit/test-columnized.sh just tests the ability to sort an array and display it in column order. It doesn't pull in the full debugger or need an interactive tty (I think). However, segregating tests is a bit of work for what strikes me as somewhat limited benefit. I generally test everything before a release. And mosts system that want to run zshdb have interactive tty's. So in the end I wonder what the overall benefit of this would be to make the tests work for a scenario that is a bit odd and out of the mainstream intended use. Therefore what I suggest is do some sort of test to see if there's an interactive tty and if not skip all of the tests. Or unconditionally skip all tests when building on Debian for packaging. 2010/2/12 Clint Adams <[email protected]> > On Fri, Feb 12, 2010 at 12:16:16PM +0100, Loďc Minier wrote: > > On Fri, Dec 11, 2009, Lucas Nussbaum wrote: > > > Relevant part: > > > > Actually that's not the whole relevant part; there's also: > > checking whether make sets $(MAKE)... yes > > get_processor:3: command not found: ps > > ./ok4zshdb.sh:43: command not found: -if > > checking Checking whether /bin/zsh is compatible with zshdb... Your zsh > doesn't have the fc -l patches. > > yes! > > checking for diff... /usr/bin/diff > > adding -w to diff in regression tests > > > > This particular problem is due to a missing build-dep on procps which > > provides ps, used in test/zsh/ok4zshdb.sh:get_processor(). > > (debootstrap --variant=buildd wont pull procps) > > > > > > > /build/user-zshdb_0.03+git20090920-1-amd64-hSCnaM/zshdb-0.03+git20090920/lib/processor.sh:37: > no such file or directory: > > > > That's the meat of the problem: lib/processor.sh:37 breaks the build > > because it uses $TTY: > > # For zsh, using this builtin parameter $TTY seems preferred over &0 > > # because it will find/fake a terminal when &0 might not be one. > > exec {_Dbg_fdi}<$TTY > > > > TTY isn't set > > > > I managed to reproduce the problem in my build environment with: > > sudo mv /dev/tty /dev/tty.bak > > env -i dpkg-buildpackage -b </dev/null >log 2>&1 > > (obviously this might break your system) > > > > So I believe the buildd environment has a partial /dev without > > /dev/tty. > > > > I tried replacing $TTY with &0, and a real file, but that didn't work > > (hit the same test failures), and with a fifo, but that hanged the > > build waiting for the fifo to fill in. > > > > I'm not familiar with zshdb, but I suspect it might need a TTY during > > debug sessions which might be why the testsuite would use one as well. > > Someone more familiar with zshdb could perhaps check whether we can use > > coproc here, or a pair of fifos (adding code to properly close them as > > well), to replace the use of $TTY. Perhaps another way would be to > > pass a script (list of commands to run) to zshdb. > > > > As a last resort, I tried running make check under "expect", but oddly > > that failed in the same way. While expect correctly sets up stdin, > > stdout, stderr on a pty, > > test/integration/check-common.sh:run_test_check() ruins that effort by > > using redirections: > > (cd $srcdir && run_debugger $debugged_script 2>&1 >$TEST_FILE > </dev/null) > > so zsh sees that stdin, stdout, and stderr aren't ttys and falls back > > to /dev/tty (which doesn't exist apparently). > > > > So I tried working around that with: > > expect -c 'spawn zsh -c "ZSH_TTY=\$$TTY $(MAKE) check"; expect' > > and changing lib/processor.sh to use ZSH_TTY. I don't know why *that* > > still fails. > > > > So it seems the only way is to rework the testsuite to not rely on > > using a real tty... > > Rocky, any thoughts? I guess at the worst case we could simply disable > the tests if no tty is available. >
