#3378 fconfigure stdout -encoding error

obsolete: 8.4.12
closed-duplicate
7
2006-03-28
2006-03-03
Anonymous
No

With 8.4.12, I see the following error (W2k, WinXP):

% info patchlevel
8.4.12
% fconfigure stdout -encoding cp437
?fconfigure stdout -encoding
???

Discussion

  • Donal K. Fellows

    • milestone: --> obsolete: 8.4.12
    • assigned_to: dkf --> andreas_kupries
    • labels: 105657 --> 25. Channel System
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-03

    Logged In: YES
    user_id=72656

    I suspect this has to do with the changes from 8.4.11 to
    8.4.12 that added Unicode console support on Windows NT.
    This screwed up Expect for Windows, but it turned out that
    that just required adopting stacked channels' encodings. Is
    it possible that this has lost us the ability to modify the
    std channel encoding?

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-03
    • priority: 5 --> 7
    • assigned_to: andreas_kupries --> patthoyts
     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    <davygrvy> here's my thoughts.. (mostly off the cuff) As
    the channel driver determines it's encoding based on the
    system it is running under, allowing it to be changed is not
    good. It isn't good cause the channel driver code isn't
    told about the change
    <ijchain> <tclguy> ok, context is that the Windows unicode
    console patch may be problematic (again)
    <davygrvy> it'd be nice if channel drivers got encoding
    change notices from the generic layer
    <davygrvy> just the unicode ones, anyways
    <davygrvy> so it can know WriteConsoleA or WriteConsoleW
    <davygrvy> calling WriteConsoleW with non-unicode after
    'fconfigure -encoding cp437' is the trap it falls into
    <davygrvy> the channel driver didn't know about the switch

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    <tclguy@Jabber> we can keep the W perhaps, but we need a
    conversion to desired encoding, no?

    The problem as I see it is that we don't really know what
    this buffer is that comes into the Tcl_DriverOutputProc. We
    could do an upconversion to unicode in the TDOP, but we'd
    take a performance hit asking what our channels encoding is,
    then perform the upcast.

    This is what I don't understand.. Why do we (as a channel
    driver) not tell the generic ourselves what we are? I mean,
    we know what the console's codepage is and how to change it
    (G|S)etConsoleCP.

    <pipedream>
    What if an optional new entry into the driver structure for
    version 5 existed so the generic layer can hook into us so
    we can apply rules for encodings? That'd be sweet..

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_81rn.asp

    Oh, you want EBCDIC? SetConsoleCP(37); failed, so I'll
    return TCL_ERROR so [fconfigure] barfs back.

    Oh.. you want unicode, set flag so our TDOP will use
    WriteConsoleW, return TCL_OK to allow [fconfigure] to change
    the generic side.
    </pipedream>

    Would that work? How much code change is that?

     
  • Don Porter

    Don Porter - 2006-03-10

    Logged In: YES
    user_id=80530

    any resolution possible
    for 8.4.13 / 8.5a4 ?

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    this is not an easy fix. A temp fix might be to not let
    [fconfigure -encoding] modify a console channel at all.

    But to do that, we still need to add a new hook vector to
    Tcl_ChannelType

     
  • Don Porter

    Don Porter - 2006-03-10

    Logged In: YES
    user_id=80530

    ok, then, is the bug
    severe enough that we
    should consider reverting
    the change that introduced it?

     
  • David Gravereaux

    Logged In: YES
    user_id=7549

    That's a tough question.. I do want to see the console
    channel driver using unicode for WriteConsoleW() on the
    systems that allow it. This is a very good thing.

    revert would be the safe descision for the moment until a
    hook method is constructed to keep the driver in sync with
    the generic layer.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-28

    Logged In: YES
    user_id=72656

    Dup of 1256872 patch. Reverted for 8.4.13, but not 8.5 (yet).

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2006-03-28
    • status: open --> closed-duplicate
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks