Find the answer to your Linux question:
Page 2 of 2 FirstFirst 1 2
Results 11 to 18 of 18
tyanata, I am running out of ideas. I did a network install of i387 Centos 5.8 and then let it do its package updates (many of them). If you did ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Just Joined!
    Join Date
    Jun 2005
    Location
    France + UK
    Posts
    15

    tyanata, I am running out of ideas. I did a network install of i387 Centos 5.8 and then let it do its package updates (many of them). If you did the same then
    there are two main differences between your installation and mine:
    1. I use VMware and not virtualbox as the virtualisation solution.
    2. My computer is an Intel I7 and not AMD - but it seems very unlikely that this is the cause.

    If you are using Centos 5.8 as the Dom0 OS running Virtualbox, does the dom0 implementation have the same fault?
    Would you also try an experiment to see if there are key events being generated.

    In a tcsh shell execute:
    xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'

    A window with a square in it should pop up having the focus. Each time that you push a key you should see the key event. i.e. if you put finger on Carriage Return you will see the key down event and raising your finger you will see the key up event.
    Now, without touching the keyboard, resize the window containing the square. Are there any false keyboard events generated?

  2. #12
    Just Joined!
    Join Date
    Apr 2012
    Posts
    12
    Hello sanktwo,

    My PC is laptop Lenovo T500.
    The command xev ... didn't respond anything when resizing terminal.

    I did some thing different - modified my try.csh script and now it looks as follows:

    #! /bin/tcsh -f

    # Trial script


    echo -n "Enter some value: "
    set tmp = $<

    showkey -a << EOF
    ${tmp}
    EOF

    echo ${tmp} | tr -d "\n" | od -An -t dC
    awk -v char=${tmp} 'BEGIN { printf " %c\n", char; exit }'


    #xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'


    if ( ${tmp} == "" ) then
    echo "Only key [Enter] is typed"
    else
    echo "The entered values = ${tmp}"
    endif

    exit 0


    When I run command source try.csh and message appears Enter some value: , if I type for example f key and then Enter. The message on the terminal is following:
    Enter some value: f
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device

    Press any keys - Ctrl-D will terminate this program

    102 0146 0x66
    10 0012 0x0a
    tcsetattr: Inappropriate ioctl for device
    102
    f
    The entered values = f


    If I respond only with Enter key the message is following:

    Enter some value:
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device

    Press any keys - Ctrl-D will terminate this program

    10 0012 0x0a
    tcsetattr: Inappropriate ioctl for device

    Only key [Enter] is typed


    If i do not respond anything but just resize the terminal the message is following:

    Enter some value: tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device

    Press any keys - Ctrl-D will terminate this program

    10 0012 0x0a
    tcsetattr: Inappropriate ioctl for device

    Only key [Enter] is typed


    So the messages from Enter key and resizing the terminal are almost the same: system accepts that '\n' ( new line ) is entered.
    Only difference which I see is in the beginning of the both results:
    - Enter key is typed:
    Enter some value:
    tcgetattr: Inappropriate ioctl for device


    - Terminal is resized:
    Enter some value: tcgetattr: Inappropriate ioctl for device


    The response of xev ... command when typing f key and Enter key gives response:
    keycode 41 = (keysym 0x66, f), state = 0x0
    keycode 41 = (keysym 0x66, f), state = 0x0
    keycode 36 = (keysym 0xff0d, Return), state = 0x0
    keycode 36 = (keysym 0xff0d, Return), state = 0x0



    The difference I see is in Enter during the program execution it is accepted as '\n' but from xev command as a '\r' ( carriage return)


    Best regards,

    tyanata
    Last edited by tyanata; 04-18-2012 at 02:14 PM.

  3. #13
    Just Joined!
    Join Date
    Jun 2005
    Location
    France + UK
    Posts
    15
    tyanata, well, rather predictably my copy did nothing when window resizing. Here is the output of running twice, once with f and the other just with carriage return:
    Enter some value: f
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device

    Press any keys - Ctrl-D will terminate this program

    102 0146 0x66
    10 0012 0x0a
    tcsetattr: Inappropriate ioctl for device
    102
    f
    The entered values = f
    [sanktwo@localhost ~]$ ./trial2.csh
    Enter some value:
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device
    tcgetattr: Inappropriate ioctl for device

    Press any keys - Ctrl-D will terminate this program

    10 0012 0x0a
    tcsetattr: Inappropriate ioctl for device

    Only key [Enter] is typed

    It is worth pointing out that typing CTRL D also appears as newline in the output i.e. the fact that the program receives newline is simply equivalent to closing the connection.
    You mentioned the conversion of carriage return to newline. The command xev shows you the key presses. I am not an expert but huge volumes are written about the problems with linefeed/carriage return between Unix and other systems (see wikipedia for example). People are used to terminating input with CR so linux converts that into its own "end of line" character which is newline when given to the script. You can terminate your line with either carriage return OR line feed (ctrl j) and you will get exactly the same result.

    The big question remains, what is causing the input termination on your system? We seem to be no nearer to locating the culprit.

    It looks like it is something to do with X windows since it is common to several window managers, several terminal emulators and shells. Also, I understand that it fails on both your workstation and on servers so it is probably not related to the graphics drivers which will be different on different hardware. But why should YOUR X behave differently to mine?


    So, can you please try one more thing. Install centos 6.2 and see if the problem remains. I know that, even if if does, will not solve your problem because of your corporate environment but it would eliminate problems directly associated with your computer and your version of virtualbox.

    I have run out of other ideas, Sorry

  4. #14
    Just Joined!
    Join Date
    Apr 2012
    Posts
    12
    Hello sanktwo,

    I will try if the issue exists on Centos6.2.

    But may be you do not reproduce my issue in right way, because you do not source the program but just run it:
    [sanktwo@localhost ~]$ ./trial2.csh

    it should be:

    [sanktwo@localhost ~]$ source ./trial2.csh

    When I just run the program without source it I also do not have problems with the terminal resizing.

    Best regards,

    tyanata

  5. #15
    Just Joined!
    Join Date
    Jun 2005
    Location
    France + UK
    Posts
    15

    grovelling apologies

    tyanata, I completely missed that it ONLY failed when using "source", I have been misleading you all along. I had no idea that there was a difference and I have never used the "source" command - sorry about wasting your time.

    When I use "source" in centos 5.8 it fails just like on your machine. There is no need for you to install Centos 6.2 it will work.
    The default version of tcsh default on centos 5.8 is 6.14 . I replaced it with 6.17 from rpmfind (not allowed to post the URL but it contains linux/RPM/centos/5.8/i386/CentOS/tcsh617-6.17-5.el5.i386 ) and the problem goes away. I feel really, really stupid. It is a fault in an old version of tcsh. THAT is one problem of having a "stable" environment!

    Here is the version info:
    [sanktwo@localhost ~]$ tcsh --version
    tcsh 6.17.00 (Astron) 2009-07-10 (i386-intel-linux) options wide,nls,dl,al,kan,rh,color,filec


    Just fyi:
    When I run it in Centos 6.2 or on Ubuntu 11.04 there is no problem with window resizing.
    When I run it in centos 5.8 or 6.2 in bash it fails instantly with:
    [sanktwo@gandalf Documents]$ source ./trial.csh
    Enter some value: bash: ./trial.csh: line 6: syntax error near unexpected token `newline'
    bash: ./trial.csh: line 6: `set tmp = $<'
    [sanktwo@gandalf Documents]$


    Just for you to check, this is the trial.csh that I have been using:
    #!/bin/tcsh -f

    # Trial script

    echo -n "Enter some value: "
    set tmp = $<

    if (${tmp} == "") then
    echo "Only key [Enter] is typed"
    else
    echo "The entered value = ${tmp} "
    endif

    exit 0


    I guess bash and tcsh "source" command behave differently.

    However, I have not tested to see if that replacement tcsh is broken in some other way!
    Once again grovelling apologies for time wasting. I think I should give up (I'm very red faced for not noticing my error earlier).

  6. #16
    Just Joined!
    Join Date
    Apr 2012
    Posts
    12
    Hello sanktwo,

    Many, many thanks for the solving my problem, everything is as you said!!!!

    tcsh --version on my Centos5.8 resulted to:
    tcsh 6.14.00 (Astron) 2005-03-25 (i386-intel-linux) options wide,nls,dl,al,kan,sm,rh,color,filec

    When removing default tcsh and installing tcsh.6.17 the same command tcsh --version results to:
    tcsh 6.17.00 (Astron) 2009-07-10 (i386-intel-linux) options wide,nls,dl,al,kan,rh,color,filec

    When using this tcsh version the terminal resizing issue is not existing.

    Most probably the same is the situation on the RedHat5.3 servers in the office, running tcsh --version on them results to:
    tcsh 6.14.00 (Astron) 2005-03-25 (x86_64-unknown-linux) options wide,nls,dl,al,kan,sm,rh,color,filec


    So I will try the same solution for them.

    Again thanks and best regards,

    tyanata

  7. #17
    Just Joined!
    Join Date
    Jun 2005
    Location
    France + UK
    Posts
    15
    Hi tyanata, I am still embarassed that it took so long - if I had not made that error it could have been fixed in a day.

    I don't know how your office computers are updated, but when you replace tcsh with a later one, you will no longer be in sync with the "official" repositories of Redhat.
    If you pay Redhat for support, the best thing to do would be to report this as a defect and ask them to fix it in their repositories. They would either have to qualify tcsh version 6.17 for Redhat 5.3 or back-port the fix for your problem to tcsh 6.14, though the latter is a bit unlikely.

    If you replace a package and for some reason Redhat decide to update their repository to another version of tcsh, you might find you get errors when doing updates since it may recognise replacing a newer version with an older one. Just bear that in mind.

    Anyway, glad to have fixed the problem for you - subject closed!

  8. #18
    Just Joined!
    Join Date
    Apr 2012
    Posts
    12
    Hello sanktwo,

    I did exactly what you said, placed official support ticket to RedHat about that bug in tcsh.6.14 el5 package.

    Thanks for the help and best regards,

    tyanata

Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •