path: root/hurd/translator/magic.mdwn

[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2013 Free Software
Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

The `magic` translator returns magic retry results, which are then resolved by
[[glibc]]'s *name lookup* routines.

[[!toc]]


# `/dev/fd`.

    $ showtrans /dev/fd
    /hurd/magic --directory fd

The `/dev/fd` directory holds the open [[unix/file_descriptor]]s for your
current process.  You can't see them with `ls -l /dev/fd/` but you can see them
individually like this:

    $ ls -l /dev/fd/0
    crw--w----  1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0


# `/dev/tty`

    $ showtrans /dev/tty
    /hurd/magic tty


## Open Issues

### IRC, OFTC, #debian-hurd, 2013-06-18

    <XTaran> http://www.zsh.org/mla/workers/2013/msg00547.html


#### IRC, OFTC, #debian-hurd, 2013-06-19

    <XTaran> youpi: http://www.zsh.org/mla/workers/2013/msg00548.html -- Is
      that realistic? If yes, can someone of you test it? I though would expect
      that if /dev/tty exists everywhere, it's a chardev everywhere, too.
    <youpi> that's not impossible indeed
    <youpi> I've noted it on my TODO list


#### IRC, OFTC, #debian-hurd, 2013-06-20

    <pinotree> youpi: wrt the /dev/tty existance,
      https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=hurd-i386&ver=46-2&stamp=1371553966
    <pinotree> For the build logs, demonstrate that /dev/null and /dev/tty
      exist:
    <pinotree> ls: cannot access /dev/tty: No such device or address
    <youpi> uh?!
    <youpi> ah, ENODEV
    <youpi> so that's what we was thinking, no tty -> no /dev/tty


#### IRC, OFTC, #debian-hurd, 2013-09-20

    <XTaran> Hi. zsh still FTBFS on Hurd due to some test failure:
      https://buildd.debian.org/status/package.php?p=zsh -- IIRC I checked last
      time on some porterbox and couldn't reproduce the failure there. Any
      insight if /dev/tty is not accessible on the buildds inside the chroot?
      Or is it no character device there? I checked on strauss and there it is
      a character device.
    <XTaran> My only other option to debug this (didn't think of that yesterday
      before the upload unfortunately) would be to override dh_auto_test with
      "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful?
    <pinotree> i see /dev/tty on exodar, in the root system and in the chroot
    <XTaran> pinotree: And it is a character device?
    <XTaran> ... in both cases?
    <pinotree> crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty
    <pinotree> yes
    <XTaran> pinotree: Hrm.
    <pinotree> (/dev in the chroot is a firmlink to the system /dev, iirc)
    <XTaran> pinotree: What is a firmlink? :)
    <XTaran> pinotree: /dev/tty belongs to your user in the example above.
    <pinotree> something between a (sym)link and an union mount
    <XTaran> pinotree: Is it possible that /dev/tty is not visible if the
      buildd runs without a connected terminal?
    <pinotree> that i'm not sure
    <XTaran> I see.
    <pinotree> wouldn't it be possible to skip only that check, instead of the
      whole test suite?
    <pinotree> maybe something like
    <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print)
    <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]]
      / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty
      found)' / [[ ! -c $zerolength ]] / fi
    <pinotree> (never used zsh, so please excuse me if i wrote something silly
      above)
    <XTaran> re
    <XTaran> pinotree: Yeah, sure. That would be one way to get the thing
      building again, if that's really the cause.
    <pinotree> i guess it would find any of the available tty* devices
    <pinotree> it does that for block devices, why not with tty devices, after
      all? :)
    <XTaran> pinotree: I just wonder if the failing test is because the test
      doesn't work properly on that architecture or because it indicates that
      there is a bug in zsh which only is present on hurd.
    <pinotree> wouldn't the change proposed above help in determining it?
    <XTaran> If I'm sure that it's a broken test, I'll try to disable that
      one. If not I'd report (more details) to upstream. :)
    <XTaran> pinotree: Oh, indeed.
    <pinotree> if you get no warning, then a tty device was found with find
      (using its -type c option), so the failing condition would be a zsh (or
      maybe something in the stack below) bug
    <pinotree> with the warning, somehow there were no tty devices available,
      hence nothing to test -c with
    <XTaran> So basically doing a check with dash to see if we should run the
      zsh test.
    <pinotree> dash?
    <XTaran> Well, whatever /bin/sh points to. :)
    <pinotree> ah, do you mean because of $(find ...)?
    <XTaran> Ah, right, -type c is from find not /bin/sh
    <XTaran> pinotree: That's my try:
      http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=ba5c7320d4876deb14dba60584fcdf5d5774e13b
    <pinotree> o_O
    <pinotree> isn't that a bit... overcomplicated?
    <XTaran> pinotree: Yeah, it's a little bit more complicated as the tests
      itself are not pure shell code but some format on their own.
    <pinotree> why not the "thing" i wrote earlier?
    <XTaran> pinotree: Actually it is what I understand you wanted to do, just
      with more debug output. Or I dunderstood 
    <XTaran> pinotree: Actually it is what I understand you wanted to do, just
      with more debug output. Or I understood your thing wrongly.
    <pinotree> <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print)
    <pinotree> <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c
      $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty
      ]] (no tty found)' / [[ ! -c $zerolength ]] / fi
    <XTaran> pinotree: Yeah, I know.
    <pinotree> that is, putting these lines instead of the current two
      tty=/dev/tty + following
    <pinotree> imho that should be fit for upstream
    <XTaran> pinotree: You mean inside C02cond.ztst?
    <pinotree> yep
    <XTaran> pinotree: No, IMHO that's a bad idea.
    <pinotree> why?
    <XTaran> pinotree: That file is to test the freshly compiled zsh. I can't
      rely on their code if I'm testing it.
    <pinotree> uh?
    <pinotree> the test above for -b is basically doing the same
    <XTaran> pinotree: Indeed. Hrm.
    <pinotree> that's where i did c&p most of it :)
    <XTaran> So upstream relies on -n in the testsuite before it has tested it?
      Ugly.
    <pinotree> if upstream does it, why cannot i too? :D
    <XTaran> pinotree: You've got a point there.
    <XTaran> Ok, rethinking. :)
    <pinotree> otoh you could just move the testcase for -n up to that file, so
      after that you know it works already
    <XTaran> pinotree: Well, if so, upstream should do that, not me. :)
    <pinotree> you could suggest them to, given the -n usage in the -b testcase
    <XTaran> pinotree: Looks alphabetically sorted, so I guess that's at least
      not accidentially.
    <XTaran> pinotree: Ok, you've convinced me. :)
    <pinotree> :D
    <XTaran> Especially because this is upstream-suitable once it proved to fix
      the Hurd FTBFS. :)
    <XTaran> pinotree: The previous upstream code (laast change 2001) instead
      of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect
      that the find may work on Cygwin, too.
    <XTaran> s/aa/a/
    <pinotree> ah, so that's that comment about globbing on cygwin was
      referring to
    <XTaran> Yep
    <pinotree> cool, so incidentally i've solved also that small issue :9
    <pinotree> :)
    <XTaran> pinotree: I hope so. :)
    <XTaran> Then again, I hope, external commands like find are fine for
      upstream.
    <pinotree> then they should rework the already existing testcases ;)
    <XTaran> pinotree: Ah, I fall again for the same assumptions. :)
    <XTaran> Seems as I would really build test suites with a different
      approach. :)
    <pinotree> nothing bad in that, i'd say
    <XTaran> I'd try to make the tests as far as possible independent from
      other tools or features to be sure to test only the stuff I want to test.
    <XTaran> Warning: Not testing [[ -c tty ]] (no tty found)
    <XTaran> Interesting. I didn't expect that outside a chroot. :)
    <pinotree> where's that?
    <XTaran> pinotree: A plain "debuild on my Sid VM.
    <pinotree> ah
    <XTaran> Linux, amd64
    <XTaran> (and Debian of course ;-)
    <XTaran> pinotree: Ah, my fault, I kept upstreams char= but didn't change
      it in your code. :)
    <pinotree> hehe
    <XTaran> pinotree: Will be included in the next zsh upload. But I don't
      want to upload a new package before the current one moved to testing (or
      got an RC bug report to fix :-)
    <pinotree> oh sure, that's fine
    <XTaran> pinotree:
      http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=22bc9278997a8172766538a2ec6613524df03742
    <XTaran> (I've reverted my previous commit)
    <pinotree> \o/


#### IRC, OFTC, #debian-hurd, 2013-09-30

    <XTaran> Anyone knows why the building of zsh on ironforge restarted? It
      was at something like "building 4h20m" when I looked last and it now is
      at "building 1h17m" but there's no old or last log, so it does still look
      like the first build.
    <pinotree> most probably got stuck
    <XTaran> Oh, ok.
    <XTaran> pinotree: So there are cases where the log is not kept?
    <pinotree> looks so
    <youpi> when the machine crashes, yes :)
    <XTaran> youpi: Ooops. Was that me?
    <youpi> no, I just rebooted the box
    <youpi> I didn't easily find which process to kill
    <XTaran> Ok. Then I'll check back tomorrow morning if pinotree's fix for
      zsh's test suite on hurd worked. :)
    <youpi> it seems to be hung on
      /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh
    <youpi> ../Src/zsh   ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst
    <XTaran> :(
    <XTaran> At least pinotree's patch worked as it then likely passed
      C02cond.ztst. :)
    <XTaran> youpi: For how long? There are multiple tests which take at least
      3 seconds per subtest.
    <youpi> one hour already
    <XTaran> Ok.
    <XTaran> That's far too long


#### IRC, OFTC, #debian-hurd, 2013-10-01

    <XTaran> pinotree: I've just checked
      https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=hurd-i386&ver=5.0.2-5&stamp=1380608100
      manually: Your fix unfortunately seemed not to help, but another test
      failed, too, and that one came later and was hence suspected as primary
      failing issue.
    <XTaran> pinotree: But "+ find: `/dev/tty': No such device or address"
      gives some hint. I just have no idea, why find issues that message.
    * XTaran really wonders how that message can be caused.
    <XTaran> So find sees /dev/tty, but gets an error if it tries to access
      (maybe only stat) it while not being connected to a terminal.
    <XTaran> Bingo: This reproduces the issue (note the missing -t option to
      ssh): ssh exodar.debian.net "find /dev/ -nowarn -maxdepth 1 -name 'tty*'
      -type c -ls"
    <XTaran> Even clearer: $  ssh exodar.debian.net "ls -l /dev/" | grep 'tty$'
    <XTaran> ls: cannot access /dev/tty: No such device or address
    <XTaran> ?????????? ? ?    ?       ?            ? tty
    <XTaran> I'd say this is a bug somewhere deep down, either in libc or the
      kernel.
    <pinotree> or in the console translator
    <XTaran> pinotree: Never heard of that so far. :)
    <XTaran> pinotree: Someone from zsh upstream suggests to use /dev/null or
      /dev/zero instead of /dev/tty* -- will try that for the next upload.
    <pinotree> ah right, /dev/null should be standard POSIX
    <XTaran> I hope so. :)
    <pinotree> http://pubs.opengroup.org/onlinepubs/9699919799/ check in POSIX
    <pinotree> in any case, sorry for the troubles it is giving you...
    <XTaran> pinotree: I'm more concerned about the hanging second test. I
      think I can get that test working with using /dev/null.
    <XTaran> Now that I've understood why the original test is failing.
    <XTaran> pinotree: Shall I write a bug report for that issue? If so,
      against which package?
    <pinotree> XTaran: not sure it is worth at this stage, having a clearer
      situation on what happens could be useful
    <pinotree> it is something that can happen sporadically, though
    <XTaran> pinotree: Well, it seems a definitely unwanted inconsistency
      between what the directory listing shows and which (pseudo) files are
      accessible. Independently of where the bug resides, this needs to be
      fixed IMHO.
    <pinotree> sure, nobody denies that
    <XTaran> pinotree: I'd call it easily reproducible. :)
    <pinotree> not really
    <XTaran> ... once you know where to look for.