I have this message on my terminal each time I open it :
/dev/fd/13:18: command not found: compdef
and when I click it says :
Your file couldn’t be accessedIt may have been moved, edited, or deleted.
ERR_FILE_NOT_FOUND
I didn't have this before, so I don't know where it come from...
can someone explain to me how to have a "clean" terminal ?
I'm on mackbook
i tried ps like they suggered here :
https://discussions.apple.com/thread/253723739
and got this :
Last login: Tue Nov 29 18:56:33 on ttys000
/dev/fd/12:18: command not found: compdef
lealee#MacBook-Pro-de-Lea ~ % ps
PID TTY TIME CMD
18250 ttys001 0:00.02 /bin/zsh -l
18384 ttys002 0:00.03 -zsh
lealee#MacBook-Pro-de-Lea ~ %
but I don't understand at all what's going on...
Related
I'm encountering a strange problem when redirecting STDOUT and STDERR. The following works as expected:
$ gvim --version > /tmp/version.out
$ ls -l /tmp/version.out
-rw-r--r--. 1 blah blah 3419 Jun 27 17:28 /tmp/version.out
There are 3419 characters in the output file and when I look at the file, it contains what I expect.
However, it does not work as expected when I do the following:
$ gvim --version > /tmp/version.out 2> /tmp/version.err
$ ls -latr /tmp/version.*
-rw-r--r--. 1 blah blah 0 Jun 27 17:29 /tmp/version.out
-rw-r--r--. 1 blah blah 0 Jun 27 17:29 /tmp/version.err
Notice that both the .out and the .err files are zero length this time. I tried this with an ls command and it works as expected:
$ ls . /ZZZ > /tmp/ls.out 2> /tmp/ls.err
$ ls -l /tmp/ls.*
-rw-r--r--. 1 blah blah 50 Jun 27 17:45 /tmp/ls.err
-rw-r--r--. 1 blah blah 33 Jun 27 17:45 /tmp/ls.out
Here, the STDERR gets redirected properly:
$ cat /tmp/ls.err
ls: cannot access /ZZZ: No such file or directory
I did an strace on gvim --version and confirmed that it's trying to write the version info to STDOUT (fd 1). It shouldn't matter either way though since I'm trying to capture both STDOUT and STDERR.
What's going on here?
Congratulations, you just found a bug in gvim!
Correct procedure is to file a new issue on GitHub.
You should first try another variations of the bug, so that developers have the debugging easier.
For example, redirecting only STDERR also causes the error, because there was no output written. Also there was returned success (0), which is obviously an bug.
$ gvim --version 2> /tmp/version.err
$ echo $?
0
By only looking into the code one may search for the bug somewhere in version printing, or anywhere in generic --version argument processing, not being done by gtk.
To answer your question
What is going on?
It's a program error, made by developers of gvim and I would not recommend you to put effort into finding its root cause unless you are experienced with coding vim or if you want to learn, how vim works. In that case, your best shot is to fork the repo and after fixing it, submitting a pull request, so that everyone can benefit from your work.
The specific condition that triggers the bug seems to be when standard error is not a terminal. When I tried redirecting standard error to another terminal device, the --version message was still printed to standard output.
ek#Io:~$ gvim --version 2>/dev/null
ek#Io:~$ tty
/dev/pts/1
ek#Io:~$ who
ek tty7 2017-07-05 02:48 (:0)
ek pts/1 2017-07-10 09:10 (192.168.10.3)
ek pts/3 2017-07-10 09:23 (192.168.10.3)
ek#Io:~$ gvim --version 2>/dev/pts/3
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 24 2016 16:44:48)
....
Apparently Vim calls isatty(2) to help figure out if it should use a terminal at all. From a comment in gui.c:
Return TRUE if still starting up and there is no place to enter text.
For GTK and X11 we check if stderr is not a tty, which means we were (probably) started from the desktop. Also check stdin, "vim >& file"
does allow typing on stdin.
But the rest of that comment (i.e., the part I didn't highlight), and instances of isatty(2) throughout multiple files, make it not immediately obvious what ought to be changed.
Running grep -RF 'isatty(2)' on the source tree revealed that this is used in gui.c, message.c, and main.c. (That doesn't mean the bug is in all those files, of course.) You might also look at all the instances of isatty in the source code.
In any case, as jirislav says, this ought to be reported as a bug--even if a full explanation of the problem is not yet apparent. I am able to reproduce this with the current upstream sources (commit 163095f).
I am trying to create a script that runs just before sleeping. Can someone tell me what I am doing wrong here? This script runs perfectly when I run the command in terminal.
king#death-star /etc/pm/sleep.d $ ls
total 1MB
drwxr-xr-x 2 root root 1MB May 30 15:21 .
drwxr-xr-x 5 root root 1MB Nov 28 2015 ..
-rwxr-xr-x 1 root root 1MB Jun 26 2015 10_grub-common
-rwxr-xr-x 1 root root 1MB Dec 6 2013 10_unattended-upgrades-hibernate
-rwxr-xr-x 1 root root 1MB May 22 2012 novatel_3g_suspend
-rwxr-xr-x 1 root root 1MB May 30 15:20 revert_kb_on_sleep
king#death-star /etc/pm/sleep.d $ cat revert_kb_on_sleep
sh -c "/home/king/Desktop/Scripts/rotate_desktop normal; /home/king/Desktop/Scripts/misc/my_keyboard on"
Output from log:
$ cat /var/log/pm-suspend.log
Running hook /etc/pm/sleep.d/revert_kb_on_sleep suspend suspend:
Can't open display
Can't open display
xrandr: --rotate requires an argument
Try 'xrandr --help' for more information.
No protocol specified
Unable to connect to X server
/etc/pm/sleep.d/revert_kb_on_sleep suspend suspend: success.
Mon May 30 15:23:39 EDT 2016: performing suspend
Mon May 30 15:27:59 EDT 2016: Awake.
Mon May 30 15:27:59 EDT 2016: Running hooks for resume
Running hook /etc/pm/sleep.d/revert_kb_on_sleep resume suspend:
Can't open display
Can't open display
xrandr: --rotate requires an argument
Try 'xrandr --help' for more information.
No protocol specified
Unable to connect to X server
/etc/pm/sleep.d/revert_kb_on_sleep resume suspend: Returned exit code 1.
Any luck with this? I wrote a script to run after waking, and I'm getting similar errors. This script is supposed to turn off the laptop display upon waking from sleep.
case "${1}" in
resume|thaw)
screen_status=$(xset -q -display :0.0 | tail -1 | sed 's/^[ \t]*//g')
if [[ "$screen_status" = "Monitor is On" ]]; then
sleep 1 && xset -display :0.0 dpms force off
fi
;;
esac
But I get the following error:
No protocol specified
xset: unable to open display ":0.0"
I've tried to get it to set screen_status as "Monitor is off" when it can't get a display, so that it triggers the condition to execute xset anyway, but that's not working, either, because it can't access the display. In the meantime, I set xfce4-power-manager to turn off the screen after 1 minute. Having to wait for a minute is better than nothing!
I just open two separated Terminal windows, and one is ttys000, the other is ttys001. I typed the command on the ttys000 window;
$ echo "Test" > /dev/ttys001
and then show up the info that "Permission denied". So I turn in the root and want to do it again like above command, but it says "Operation not supported"...
I thought the ttys001 window should show the "Test" string.
Why this happen?
How can i read the content of a xterm or terminal, only by knowing its device number?
Similar to moving the mouse over the text.
Redirecting or cloning the terminal output to a file would be an option too, as long it could be done without interacting with commands executed in this terminal.
So nothing like 'command > myfile'.
Or is the only way to solve this a print screen with ocr or simulating mouse moves and clicks?
Edit: I m looking for a solution that reads the content regardless of his origin, p.e. 'echo "to tty" > /dev/pts/1'
The script command may work for you.
"Script makes a typescript of everything printed on your terminal. It is useful for students who need a hardcopy record of an interactive session as proof of an assignment, as the typescript file can be printed out later" - man script
You can even pass script as command when invoking xterm with -e:
ubuntu#ubuntu:~$ xterm -e script
ubuntu#ubuntu:~$ # A new xterm is started. uname is run, then exit
ubuntu#ubuntu:~$ # The output is captured to a file called typescript, by default:
ubuntu#ubuntu:~$ cat typescript
Script started on Tue 19 Nov 2013 06:00:07 PM PST
ubuntu#ubuntu:~$ uname
Linux
ubuntu#ubuntu:~$ exit
exit
Script done on Tue 19 Nov 2013 06:00:13 PM PST
ubuntu#ubuntu:~$
(Edit: There was a typo that caused the problem. Please see comments on existing answers)
I wanted to stat a file that symlinked to another file and thought that I could use subshells and readlink command substitution to do the job. For context, let me mention that this is on OS X 10.8.3 (Darwin).
But I ran into a permission denied error.
ujagtahb#ujags-Retina-MBP-5.local:~/Code_Pen/c_exp$(cd /usr/share/locale/; stat $(en_US/LC_COLLATE))
bash: en_US/LC_COLLATE: Permission denied
727393128 1449 crw--w---- 1 ujagtahb tty 268435496 0 "Aug 12 11:36:50 2013" "Aug 12 11:36:51 2013" "Aug 12 11:36:51 2013" "Aug 12 11:36:51 2013" 131072 0 0 (stdin)
I checked the output of the readlink command and sure enough, I didn't see anything wrong with it.
ujagtahb#ujags-Retina-MBP-5.local:~/Code_Pen/c_exp$readlink /usr/share/locale/en_US/LC_COLLATE
../la_LN.US-ASCII/LC_COLLATE
stating the file directly raised no error and produced the output I needed.
ujagtahb#ujags-Retina-MBP-5.local:~/Code_Pen/c_exp$stat /usr/share/locale/la_LN.US-ASCII/LC_COLLATE
16777218 284538 -r--r--r-- 1 root wheel 0 2086 "Aug 12 11:36:51 2013" "Jul 22 07:55:02 2012" "Jul 22 07:55:02 2012" "Jun 21 01:35:25 2012" 4096 0 0x20 /usr/share/locale/la_LN.US-ASCII/LC_COLLATE
What's causing the permission denied in one case but not the other?
This:
(cd /usr/share/locale/; stat $(en_US/LC_COLLATE))
means "open a subshell, cd to /usr/share/locale, run the command en_US/LC_COLLATE, and run stat on the output".
But I think the command you want to run is readlink en_US/LC_COLLATE, not en_US/LC_COLLATE; so:
(cd /usr/share/locale/; stat $(readlink en_US/LC_COLLATE))
(I'm guessing this was just a typo?)
$(en_US/LC_COLLATE)
will execute string en_US/LC_COLLATE as command (script).
Since it does not have execute permission shell will output that error.
Probably you wanted to do it that way:
$(cd /usr/share/locale/; stat en_US/LC_COLLATE)