.snap: zero-sized eps file
hanin wrote on Dec 28, 2007
Hello,
I'm running IRAF v2.13-beta2 on Ubuntu 7.04 - works fine but I could not create good eps file from the graphics output. I used the usual way: ".snap epsf". The eps file did generated but its size is always 0 bytes and could not be opened. Any help please? Thanks.
Hanindyo Kuncarayakti
I'm running IRAF v2.13-beta2 on Ubuntu 7.04 - works fine but I could not create good eps file from the graphics output. I used the usual way: ".snap epsf". The eps file did generated but its size is always 0 bytes and could not be opened. Any help please? Thanks.
Hanindyo Kuncarayakti
Mike Fitzpatrick wrote on Dec 28, 2007
Be sure that the ":.snap" is followed by a ":.gflush" (or a "gflush" from the CL prompt) to flush the graphics buffer and complete the file.
Otherwise, the SGI translators are executed using the 'sgidispatch' command installed in with the rest of the iraf commands (e.g. cl, mkiraf, etc). This is usually in the /usr/local/bin directory, but that directory needs to be in the default path defined in the .cshrc/.profile because of how the command is spawned. Doing a "cl> !which sgidispatch" will tell you whether that directory is being found.
Cheers,
-Mike
Otherwise, the SGI translators are executed using the 'sgidispatch' command installed in with the rest of the iraf commands (e.g. cl, mkiraf, etc). This is usually in the /usr/local/bin directory, but that directory needs to be in the default path defined in the .cshrc/.profile because of how the command is spawned. Doing a "cl> !which sgidispatch" will tell you whether that directory is being found.
Cheers,
-Mike
hanin wrote on Dec 28, 2007
Dear sir,
thanks for your comment. I used gflush after snap, but it still not worked (still 0 bytes size). The sgidispatch is indeed in /usr/local/bin directory, but I don't understand what you mean by ".cshrc/.profile".
thanks for your comment. I used gflush after snap, but it still not worked (still 0 bytes size). The sgidispatch is indeed in /usr/local/bin directory, but I don't understand what you mean by ".cshrc/.profile".
Mike Fitzpatrick wrote on Dec 28, 2007
The sgidispatch is run in a shell spawned to execute the command. The type of shell depends mostly on what your login shell is, i.e. C-shell or a
Bourne shell (or 'bash'). If you normally use a C-shell then the .cshrc file in your unix login directory will be read to get the environment, for Bourne shells it will be a .profile or .bashrc file. If you only define your search path in a .login file, then the environment for the sgidispatch command will be the system default and may not include a /usr/local/bin directory.
Doing a "cl> !which sgidispatch" will return a path to the command if it is found, or a 'command not found' message if it isn't. If it isn't found edit the .cshrc or .profile so the PATH includes the proper directory.
I also just noticed you're using v2.13 on Ubuntu: This system didn't include binaries in for the 'linux' architecture in the $iraf/unix/bin.linux directory and so the sgidispatch and other files would be missing. To fix this, copy (don't simply move) the contents of $iraf/unix/bin.redhat to $iraf/unix/bin.linux I suspect now this is the real cause.
-Mike
Bourne shell (or 'bash'). If you normally use a C-shell then the .cshrc file in your unix login directory will be read to get the environment, for Bourne shells it will be a .profile or .bashrc file. If you only define your search path in a .login file, then the environment for the sgidispatch command will be the system default and may not include a /usr/local/bin directory.
Doing a "cl> !which sgidispatch" will return a path to the command if it is found, or a 'command not found' message if it isn't. If it isn't found edit the .cshrc or .profile so the PATH includes the proper directory.
I also just noticed you're using v2.13 on Ubuntu: This system didn't include binaries in for the 'linux' architecture in the $iraf/unix/bin.linux directory and so the sgidispatch and other files would be missing. To fix this, copy (don't simply move) the contents of $iraf/unix/bin.redhat to $iraf/unix/bin.linux I suspect now this is the real cause.
-Mike
hanin wrote on Dec 28, 2007
Sorry maybe I don't understand exactly what you mean - I truly am not an expert in IRAF or UNIX, simply just a user :)
I will try to explain the situation more clearly (AFAIK).
Usually I start IRAF by clicking a launcher, which was set to launch the command
Now the xgterm window is opened and CL is activated (the working directory is my home directory at /home/hanin)
Then I try to snap from a graphics output (irafterm):
In irafterm, I executed
Now I'm back to the xgterm window. File sgi7711.eps is generated with 0 bytes of size.
To make sure the sgidispatch is in its place,
So it's in the directory as indicated by you. The default shell I used in Ubuntu is bash. I found the .bashrc and .profile file but don't know which part of it should be edited.
As you suggested, I tried to copy the contents of $iraf/unix/bin.redhat to $iraf/unix/bin.linux, but there's no file in the bin.redhat directory
There's the situation and I'm still confused why it won't work...
FYI I usually grab a jpg image from the graphics output using take-screenshot programs and converted it to eps afterwards. Sorry if my question about this direct eps grabbing doesn't seem to be important, but I'm just curious. :)
Many thanks,
Hanin.
I will try to explain the situation more clearly (AFAIK).
Usually I start IRAF by clicking a launcher, which was set to launch the command
xgterm -sb -bg black -fg darkkhaki -title "Image Reduction and Analysis Facility
(IRAF)" -e "ecl" &Now the xgterm window is opened and CL is activated (the working directory is my home directory at /home/hanin)
IRAFNET PC-IRAF Revision 2.13-BETA2 Wed Apr 19 21:21:13 MST 2006
This is the IRAFNET version of IRAF V2.13 supporting PC systems.
_ _
(_) _ _ __ _ / _| _ _ ___ | |_ http://iraf.net
| || '_|/ _` || _| | ' \ / -_)| _| IRAF Software and
|_||_| \__,_||_| ()|_||_|\___| \__| User Support
Welcome to IRAF. To list the available commands, type ? or ??. To get
detailed information about a command, type `help <command>'. To run a
command or load a package, type its name. Type `bye' to exit a
package, or `logout' to get out of the CL.
Please visit http://iraf.net if you have questions, to report problems,
or would like to help to support this project.
The following commands or packages are currently defined:
ace. dimsum. guiapps. mxtools. plot. system.
color. fitsutil. images. nlocal. proto. tables.
ctio. fuzzy. language. nmisc. softools. utilities.
dataio. gemini. lists. noao. spectime. vol.
dbms. gmisc. mscred. obsolete. stsdas. websvc.
ecl>
Then I try to snap from a graphics output (irafterm):
ecl> implot dev$pixIn irafterm, I executed
:.snap epsf
:.gflush
qNow I'm back to the xgterm window. File sgi7711.eps is generated with 0 bytes of size.
To make sure the sgidispatch is in its place,
ecl> !which sgidispatch
/usr/local/bin/sgidispatchSo it's in the directory as indicated by you. The default shell I used in Ubuntu is bash. I found the .bashrc and .profile file but don't know which part of it should be edited.
As you suggested, I tried to copy the contents of $iraf/unix/bin.redhat to $iraf/unix/bin.linux, but there's no file in the bin.redhat directory
ecl> !ls $iraf/unix/bin.redhat
ecl> !ls $iraf/unix/bin.linux
alloc.e libboot.a mkpkg.e sgi2uapl.e sgi2uqms.e xyacc.e
f2c.1 libboot_p.a rmbin.e sgi2ueps.e sgi2xbm.e
f2c.1.gz libcompat.a rmfiles.e sgi2uhpgl.e sgidispatch.e
f2c.e libf2c.a rpp.e sgi2uhplj.e wtar.e
f2c.h libos.a rtar.e sgi2uimp.e xc.e
generic.e libos_p.a sgi2gif.e sgi2uptx.e xpp.e
There's the situation and I'm still confused why it won't work...
FYI I usually grab a jpg image from the graphics output using take-screenshot programs and converted it to eps afterwards. Sorry if my question about this direct eps grabbing doesn't seem to be important, but I'm just curious. :)
Many thanks,
Hanin.
Mike Fitzpatrick wrote on Dec 28, 2007
The problem is that the $iraf/unix/bin.redhat contents have been apparently moved to the bin.linux directory and not simply copied. The binaries are compiled with architecture flags for the system on which they were built, and so while having the sgidispatch command will have it found in the bin.linux directory, it executes and builds a path to the appropriate SGI translator using the hardwired architecture and the translator isn't being found in the bin.redhat directory.
To fix it, COPY the contents of bin.linux back to bin.redhat so the full set of files is in both directories.
-Mike
To fix it, COPY the contents of bin.linux back to bin.redhat so the full set of files is in both directories.
-Mike
hanin wrote on Dec 28, 2007
Thank you for your last post. It worked :)
Gordon Petrie wrote on Dec 28, 2007
I'm a novice user with a problem creating eps files. I use the command gkimosaic to create a 10^2 mosaic of graphs. This mosaic looks perfect in the irafterm window. I then type
:.snap epsf
:.gflush
q
The resulting eps file is incomplete - it contains about 9 1/2 columns of plots. What should I do to complete the file?
Thanks,
Gordon
:.snap epsf
:.gflush
q
The resulting eps file is incomplete - it contains about 9 1/2 columns of plots. What should I do to complete the file?
Thanks,
Gordon
Mike Fitzpatrick wrote on Dec 28, 2007
If the graphics file is incomplete, especially for a large mosaic of plots like this, it usually just means the graphics buffer isn't large enough. This buffer is defined by the 'cmbuflen' variable to something like 128K chars, but you can simply uncomment the setting in your login.cl file where it'll be larger. Otherwise, on the cmdline do a
and try again.
-Mike
cl> reset cmdbuflen = 512000
cl> gflush
cl> flpr
and try again.
-Mike
Gordon Petrie wrote on Dec 28, 2007
Thanks, Mike, for your fast reply. That succeeded.
Frank Winkler wrote on Dec 28, 2007
Hi,
I have the same problem with a zero-sized eps file resulting when I do a
:.snap in a graphics window.
I looked for sgidispatch in an xterm window (on my Intel Mac), and it is there in the search path, as expected:
% which sgidispatch
/usr/local/bin/sgidispatch
The directory /usr/local/bin/ is included in my .bashrc file.
But now if I try the same thing from my iraf xgterm window, it's not found:
ecl> !which sgidispatch
no sgidispatch in /usr/bin /bin /usr/sbin /sbin
ecl>
Apparently the xgterm startup reads a different file (.i.e., not .bashrc). What file is this, and how do I fix it?
Thanks!
Paco
I have the same problem with a zero-sized eps file resulting when I do a
:.snap in a graphics window.
I looked for sgidispatch in an xterm window (on my Intel Mac), and it is there in the search path, as expected:
% which sgidispatch
/usr/local/bin/sgidispatch
The directory /usr/local/bin/ is included in my .bashrc file.
But now if I try the same thing from my iraf xgterm window, it's not found:
ecl> !which sgidispatch
no sgidispatch in /usr/bin /bin /usr/sbin /sbin
ecl>
Apparently the xgterm startup reads a different file (.i.e., not .bashrc). What file is this, and how do I fix it?
Thanks!
Paco
Mike Fitzpatrick wrote on Dec 28, 2007
Hi Frank,
You need to first do an "% echo $SHELL" from the unix prompt to see what kind of shell you're using, if the reply is csh/tcsh then you need to put the /usr/local/bin directory in the path defined in your .cshrc file. In most cases a regular terminal window will be a "login shell" and so will read your .login file, but for the escaped commands like when printing, only the .cshrc or .bashrc/.profile is read.
Cheers,
-Mike
You need to first do an "% echo $SHELL" from the unix prompt to see what kind of shell you're using, if the reply is csh/tcsh then you need to put the /usr/local/bin directory in the path defined in your .cshrc file. In most cases a regular terminal window will be a "login shell" and so will read your .login file, but for the escaped commands like when printing, only the .cshrc or .bashrc/.profile is read.
Cheers,
-Mike
Frank Winkler wrote on Dec 28, 2007
thanks Mike-
When I tried this from a cl terminal window:
ecl> ! echo $SHELL
/bin/bash
so why didn't it read the .bashrc file and thus pick up the path to find sgidispatch, I wondered.
Well, I had launched IRAF via the "iraf button" on my Mac, the lazy way, I guess. But when I explicitly launch an xgterm window, and then the cl, then everything works just fine. The lesson here (for me anyhow) is simply not to use the iraf button to launch iraf. Not much to give up.
Thanks,
Frank
When I tried this from a cl terminal window:
ecl> ! echo $SHELL
/bin/bash
so why didn't it read the .bashrc file and thus pick up the path to find sgidispatch, I wondered.
Well, I had launched IRAF via the "iraf button" on my Mac, the lazy way, I guess. But when I explicitly launch an xgterm window, and then the cl, then everything works just fine. The lesson here (for me anyhow) is simply not to use the iraf button to launch iraf. Not much to give up.
Thanks,
Frank
Last post on Dec 28, 2007