Find the answer to your Linux question:
Results 1 to 10 of 10
I have a command running like: Code: tail -f logfile.txt That's the difference between using ctrl+c or ctrl+z or ctrl+d ctrl+c seems like will terminate the program. but with ctrl+z ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Guru Lakshmipathi's Avatar
    Join Date
    Sep 2006
    Location
    3rd rock from sun - Often seen near moon
    Posts
    1,758

    Question [SOLVED] Difference bw ctrl C & ctrl D & ctrl Z


    I have a command running like:
    Code:
    tail -f logfile.txt
    That's the difference between using
    ctrl+c or
    ctrl+z or
    ctrl+d

    ctrl+c seems like will terminate the program.
    but with ctrl+z is suspended ?
    what's this ctrl+d will do ?
    First they ignore you,Then they laugh at you,Then they fight with you,Then you win. - M.K.Gandhi
    -----
    FOSS India Award winning ext3fs Undelete tool www.giis.co.in. Online Linux Terminal http://www.webminal.org

  2. #2
    Linux Enthusiast gerard4143's Avatar
    Join Date
    Dec 2007
    Location
    Canada, Prince Edward Island
    Posts
    714

    control d

    You can use control d for EOF(end of file)

  3. #3
    Linux Guru Lakshmipathi's Avatar
    Join Date
    Sep 2006
    Location
    3rd rock from sun - Often seen near moon
    Posts
    1,758

    Smile

    Thanks gerard4143
    So finally
    Ctrl + C To terminate
    Ctrl + D signals EOF
    Ctrl + Z suppends a program

    HTH someone.
    First they ignore you,Then they laugh at you,Then they fight with you,Then you win. - M.K.Gandhi
    -----
    FOSS India Award winning ext3fs Undelete tool www.giis.co.in. Online Linux Terminal http://www.webminal.org

  4. #4
    Linux Guru Cabhan's Avatar
    Join Date
    Jan 2005
    Location
    Seattle, WA, USA
    Posts
    3,252
    Just to clarify a bit: what Ctrl-C actually does is send a SIGQUIT signal to the process. A process is able to intercept this signal and do whatever it likes: for instance, from your Bash prompt, try hitting Ctrl-C. In Bash, it just cancels whatever you've typed and gives you a blank prompt (as opposed to quitting Bash).

  5. #5
    Linux Engineer wje_lf's Avatar
    Join Date
    Sep 2007
    Location
    Mariposa
    Posts
    1,192

    too much information

    Here it goes: I'm posting too much information, I'm sure.
    [W]hat Ctrl-C actually does is send a SIGQUIT signal to the process.
    Actually, the signal usually associated with the ^C character is not SIGQUIT, but SIGINT.

    With that slight modification, what Cabhan says is true in normal circumstances. And this is definitely true:
    A process is able to intercept this signal and do whatever it likes
    But there are more ways in which a running program can do whatever it likes.

    First, it can associate with each of certain signals any ASCII character it likes. In addition, it is customary to specify the character hex FF to mean "Don't let any key on the keyboard cause this signal to be sent." Then your program doesn't have to go out of its way to explicitly ignore that signal or catch it.

    Here are some signals, and the characters usually associated with them (which are overridable by the running program):
    Code:
    SIGINT   ^C   (default action: terminate the process)
    SIGQUIT  ^\   (default action: terminate the process and dump to a core file)
    SIGSUSP  ^Z   (default action: suspend the process)
    As Cabhan says, for each of these signals, a running program can either accept the default action, ignore the signal, or specify some other action written in the program's code.

    Beyond signals, the running program can also specify which character (if any) is the end of file character. The default character for this, as gerard4143 and Lakshmipathi say, is ^D.

    The interested C programmer would do well to type this at the shell prompt:
    Code:
    man tcsetattr
    --
    Bill

    Old age and treachery will overcome youth and skill.

  6. #6
    Linux Guru Cabhan's Avatar
    Join Date
    Jan 2005
    Location
    Seattle, WA, USA
    Posts
    3,252
    Right, so I thought it was SIGINT, but I wasn't sure, and I checked signal(7), and saw SIGQUIT as "Interrupt from keyboard".

    I have now rechecked that, and have seen that I was reading the wrong line <_<;.

  7. #7
    Linux Engineer wje_lf's Avatar
    Join Date
    Sep 2007
    Location
    Mariposa
    Posts
    1,192
    I was reading the wrong line
    That's ok. I never make mistakes. (cough cough CHOKE)
    --
    Bill

    Old age and treachery will overcome youth and skill.

  8. #8
    Linux Guru Lakshmipathi's Avatar
    Join Date
    Sep 2006
    Location
    3rd rock from sun - Often seen near moon
    Posts
    1,758

    Smile

    Thanks guyz - For providing more insight to this topic
    First they ignore you,Then they laugh at you,Then they fight with you,Then you win. - M.K.Gandhi
    -----
    FOSS India Award winning ext3fs Undelete tool www.giis.co.in. Online Linux Terminal http://www.webminal.org

  9. #9
    drl
    drl is online now
    Linux Engineer drl's Avatar
    Join Date
    Apr 2006
    Location
    Saint Paul, MN, USA / CentOS, Debian, Slackware, {Free, Open, Net}BSD, Solaris
    Posts
    1,288
    Hi.

    I like the way Stevens wrote in these topics:
    The handling of terminal I/O is a messy area, regardless of the operating system. (Terminal I/O, Chapter 11)

    Signals are software interrupts.
    (Signals, Chapter 10)
    If you are interested enough to explore farther, see the book below ... cheers, drl
    Code:
    Title: Advanced Programming in the UNIX(R) Environment
    Author: W. Richard Stevens
    Edition: 1st
    Date: 1992
    Publisher: Addison-Wesley Professional
    ISBN: 0-201-56317-7
    Pages: 768
    Categories:  unix, system calls, programming, coding
    Comments: 4.5 stars at Amazon; there is a second edition 2005
    Welcome - get the most out of the forum by reading forum basics and guidelines: click here.
    90% of questions can be answered by using man pages, Quick Search, Advanced Search, Google search, Wikipedia.
    We look forward to helping you with the challenge of the other 10%.
    ( Mn, 2.6.n, AMD-64 3000+, ASUS A8V Deluxe, 1 GB, SATA + IDE, Matrox G400 AGP )

  10. #10
    Linux Engineer wje_lf's Avatar
    Join Date
    Sep 2007
    Location
    Mariposa
    Posts
    1,192

    Yes!

    I agree. Advanced Programming in the UNIX Environment rocks, as do W. Richard Stevens's books on network programming.
    --
    Bill

    Old age and treachery will overcome youth and skill.

Posting Permissions

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