What could be enabling --vi-keys in GNU Info - emacs

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.

Related

checking to see if files are executable perl

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 ;)

Current working directory for SXPG_COMMAND_EXECUTE?

Is there a way to specify the current working directory for the system command executed by the function module SXPG_COMMAND_EXECUTE?
I do not see any parameter which would allow me to do that either by defining the command in transaction SM69 or on the list of IMPORTING parameters in SE37.
It looks like by default such commands are started in DIR_HOME which can be viewed by the transaction AL11. Do I have any control over that?
There isn't a way of doing it via `SM69' unfortunately. I think the only solution is to create a script and call that.
I was going to suggest wrapping the statements in a SM69 command defined as a call to sh with parameters of -c 'cd <dir> && /path/to/command' but unfortunately that doesn't work. According to note 401095 wildcards are not permitted. When I tested, && was translated into a single &, causing the command to fail.
Would be good if you access this information using FM FILE_GET_NAME_USING_PATH (export the script name for which you want to find the physical directory).
The recieving path can be used in SXPG_COMMAND_EXECUTE.
Because the external commands I called were actually .bat files I solved this by putting the following expression at the beginning of each and every one.
cd /d %~dp0
This Stackoverflow question helped a lot actually.

Pipe output to environment variable export command

I'm trying to set a git hash value into an environment variable, i thought it would be as simple as doing this:
git log --oneline -1 | export GIT_HASH=$1
But the $1 doesn't contain anything. What am I doing wrong?
$1 is used to access the first argument in a script or a function. It is not used to access output from an earlier command in a pipeline.
You can use command substitution to get the output of the git command into an environment variable like this:
GIT_HASH=`git log --oneline -1` && export GIT_HASH
However...
This answer is specially in response to the question regarding the Bourne Shell and it is the most widely supported. Your shell (e.g. GNU Bash) will most likely support the $() syntax and so you should also consider Michael Rush's answer.
But some shells, like tcsh, do not support the $() syntax and so if you're writing a shell script to be as bulletproof as possible for the greatest number of systems then you should use the `` syntax despite the limitations.
Or, you can also do it using $(). (see What is the benefit of using $() instead of backticks shell scripts?)
For example:
export FOO_BACKWARDS=$(echo 'foo' | rev)
You can use an external file as a temporary variable:
TMPFILE=/var/tmp/mark-unsworth-bashvar-1
git log --oneline -1 >$TMPFILE; export GIT_HASH=$(cat $TMPFILE); rm $TMPFILE
echo GIT_HASH is $GIT_HASH

Can I change the location of the file emacs writes to in the process of printing?

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.

info files in subdirectory is not recognized in emacs

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?