I installed an additional info file using
install-info /usr/share/info/asymptote/asymptote.info.gz /usr/share/info/dir
it is perfectly visible by info command from the command line, i.e. info asymptote return content of asymptote/asymptote.info.gz properly. Also it is visible by emacs in the top node when I use M-x info command, but when I try to go to asymptote node, it complains "Info-find-file: Info file asymptote does not exist". The problem looks similar to info indexing (within and without emacs) although it is not quite the same. It seems that info command in emacs does not recognize the subdirectory, while the original info command does. Is it possible to force emacs behave in the same way?
My understanding is that the main directory listing for M-x info is built from dir files found under directories in the Info-directory-list variable, and that same variable is used when searching for a named info file; so this is slightly odd.
You should verify that Info-suffix-list contains an entry for .info.gz, but that should be pretty standard, so my best guess is that the dir entry added by install-info is not quite correct (or not supported, at any rate).
Could you show us what the entry for asymptote looks like in /usr/share/info/dir?
Related
I have a script regularly appending to a log file. When I use entr (discovered here) to monitor that log file, and I then touch the log, everything works fine, but when the script appends to the file, entr fails. This may be because I have noatime set in my fstab - but that only stops the updating of the access time not the modify time, so this confuses me.
I've checked and while atime is not updating, ctime (ls -lc) definitely is. Could entr really be depending on atime? I use noatime because I have an SSD. So what should I do? I just stumbled on lazytime. Would that solve the problem?
Since monitoring the log file was not working, I tried entr -cdr on the directory of files that are updated (a new file is created) at the same time as the log (the log is in a different directory). entr recognizes when the directory contents change, but the -r does not work. The entr process just ends, saying "entr: directory altered".
Any idea how to fix this or whether I should just go back to inotify, would be appreciated.
Edit: I have written it with inotify now, and the event reported when the log file is written to is, sensibly enough, "MODIFY."
It turns out that entr does not respond to IN_MODIFY events, but only to these (in Linux):
IN_CLOSE_WRITE|IN_DELETE_SELF|IN_MOVE_SELF|IN_CREATE
Also, IN_ATTRIB, but only if the file-mode or inode numbers change.
In BSD/OSX, it's:
NOTE_DELETE|NOTE_WRITE|NOTE_RENAME|NOTE_TRUNCATE|NOTE_ATTRIB
Also, the option -r has no effect in the context of the -d option. It only works when entr is monitoring files.
See the developer's comments. Also, more info on entr.
I have a program that checks to see if the files in my directory are readable,writeable, and executable.
i have it set up so it looks like
if (-e $file){
print "exists";
}
if (-x $file){
print "executable";
}
and so on
but my issue is when I run it it shows that the text files are executable too. Plain text files with 1 word in them. I feel like there is an error. What did I do wrong. I am a complete perl noob so forgive me.
It is quite possible for a text file to be executable. It might not be particularly useful in many cases, but it's certainly possible.
In Unix (and your Mac is running a Unix-like operating system) the "executable" setting is just a flag that is set in the directory entry for a file. That flag can be set on or off for any file.
There are actually three of these permissions why record if you can read, write or execute a file. You can see these permissions by using the ls -l command in a terminal window (see man ls for more details of what various ls options mean). There are probably ways to view these permissions in the Finder too (perhaps a "properties" menu item or something like that - I don't have a Mac handy to check).
You can change these permissions with the chmod ("change mode") command. See man chmod for details.
For more information about Unix file modes, see this Wikipedia article.
But whether or not a file is executable has nothing at all to do with its contents.
The statement if (-x $file) does not check wether a file is an executable but if your user has execution priveleges on it.
For checking if a file is executable or not, I'm affraid there isn't a magic method for it. You may try to use:
if (-T $file) for checking if the file has an ASCII or UTF-8 enconding.
if (-B $file) for checking if the file is binary.
If this is unsuitable for your case, consider the following:
Assuming you are on a Linux enviroment, note that every file can be executed. The question here is: The execution of e.g.: test.txt, is going to throw a standard error (STDERR)?
Most likely, it will.
If test.txt file contains:
Some text
And you launched it in your Perl script by: system("./test.txt"); This will display a STDERR like:
./test.txt: line 1: Some: command not found
If for some reason you are looking to run all the files of your directory (in a for loop for instance) be warned that this is pretty dangerous, since you will launch all your files and you may not be willing to do so. Specially if the perl script is in the same directory that you are checking (this will lead to undesirable script behaviour).
Hope it helps ;)
Though I'm not invoking Info with the --vi-keys option, it seems to be in effect: e.g., though the help states...
'?' lists all Info commands;
...hitting ? actually invokes "Regexp search backward". I've verified that there are no aliases for info in effect.
A common shell (bash or zsh) alias is:
alias info='info --vi-keys'
You can check your aliases to see if this exists with:
alias | grep vi-keys
If that is the case, look for it in personal and system start-up
files, and remove the line.
Our network system is set up such that we can not write directly to the root directory (C:) so I get the following error when attempting to print.
Spooling with options (page headers are not supported)...
direct-print-region-helper: Opening output file: permission denied, c:/IP_139.222.92.102
If I could somehow change the location that emacs is attempting to write to (anywhere else) it would likely work.
GNU emacs 24.3.1 running on MS Win 7
I tried various solutions given in this thread and others with no success. I saw someone has commented about quoting the slashes. So, I entered
(setq printer-name "\\\\MyComputer\\HP8600")
(setq ps-printer-name "\\\\MyComputer\\HP8600")
in the .emacs file, and SUCCESS. Obviously you will have to change the names "MyComputer" to match your computer and HP8600 to your printer name (both available via Control Panel).
Adjust pr-temp-dir, e.g.:
(setq pr-temp-dir "c:/some/other/location")
After requiring 'printing, C-h v pr-temp-dir on my Linux system gives:
pr-temp-dir is a variable defined in `printing.el'.
Its value is "/tmp/"
Documentation:
Specify a directory for temporary files during printing.
See also `pr-ps-temp-file' and `pr-file-modes'.
You can customize this variable.
You may have to play with quoting or escaping a Windows-style path.
Let's see if I can reach the EmacsW32 users on stackoverflow.
I've just installed the patched version of EmacsW32 from http://ourcomments.org/Emacs/EmacsW32.html
I find it very nice that .txt files are associated wth Emacs, so that when you click on one, emacsclient opens it in the running instance of Emacs.
Problem is, for some reason, the buffer is renamed with the old-style shortened file names, so, for example, the buffer with file "activities-2008.txt" is renamed to "ACTIV~1.TXT", which I don't like.
How do I get EmacsW32 not to rename the buffer, and use the whole file name as the buffer name instead ?
Ick, that sucks.
Why not just use the emacsclientw that comes with the standard Windows emacs distribution?
It does have a bit of an issue in that you get an annoying "No error" error box if Emacs isn't already running, but any real emacs user starts emacs first thing when they log on anyway. :-)
Solved.
The problem is not with emacs, but with the way Windows runs a program when a file type is associated in the registry.
In my registry, I had this value for the keys that associate txt files with Emacs:
C:\emacs-23.0.91.1\Emacs\bin\emacsclientw.exe -n "%1"
The problem is the %1, which is replaced by a short file name.
According to this message http://lists.gnu.org/archive/html/help-emacs-windows/2009-05/msg00022.html:
%L is long file names.
%1 is long file names IF
* Explorer can find the exe file (it does not look very hard)
AND
* The file header says it is Win 95 aware Win16 exe, or
* It is a 32 bit program
Else %1 will be a short name.
The solution is to use %L in place of %1 in the reg keys.