Hi,

Bernadette Wagner writes:

I need to install this file I've downloaded and don't know Linux well enough to do so. (If it had an rpm, I think I could do it. So, please advise if there is an rpm or how to do it otherwise.

The GDynText plug-in is part of the GIMP-1.2 distribution. If you have GIMP-1.2 installed, you already have GDynText version 1.5.4.

Sven

On Friday 09 May 2003 12:19 am, Bernadette Wagner wrote:

Help again, please!

I need to install this file I've downloaded and don't know Linux well enough to do so. (If it had an rpm, I think I could do it. So, please advise if there is an rpm or how to do it otherwise.

TIA,

B-)

Hi,

John Culleton writes:

If you use Linux you had best become familiar with the few commands below:

You better be careful following such advices since most of the things John suggested are rather dangerous and would better be done differently.

1. Go to a command prompt by using e.g.,

Using a terminal emulation such as xterm, gnome-terminal or similar is probably more appropriate if you are working on X window system.

Change directories to where you put the file. cd /home/user
2.Move the file to where you need it, e.g., /usr/local cp foo.tgz /usr/local
3. Now go there.
cd /usr/local
4. Unpack the file in one step
tar zxvf foo.tgz

I would not suggest to unpack anything in /usr/local. You might mess up your system badly. Always unpack and build source pacakegs outside the directory tree where they are going to be installed.

5. Unpacking it will (probably) create a directory with files in it. cd to that directory and read (using less) the README, INSTALL etc. files that are present. To get a list of files use the command

In case of GIMP plug-ins, we are usually talking about a single C file that needs to be compiled and installed. GIMP comes with a simple command-line tool called gimptool that helps you with this task. It has a nice man-page, read it.

Sven

On Friday 09 May 2003 12:45 pm, Sven Neumann wrote:

Hi,

John Culleton writes:

If you use Linux you had best become familiar with the few commands below:

You better be careful following such advices since most of the things John suggested are rather dangerous and would better be done differently.

1. Go to a command prompt by using e.g.,

Using a terminal emulation such as xterm, gnome-terminal or similar is probably more appropriate if you are working on X window system.

Why more apropriate? The experienced Linux user uses whatever is handy at the moment. For commmand line use unless I need to jump right back into a graphic application I find the alternate console easier to read.

Change directories to where you put the file. cd /home/user 2.Move the file to where you need it, e.g., /usr/local cp foo.tgz /usr/local 3. Now go there. cd /usr/local 4. Unpack the file in one step tar zxvf foo.tgz

I would not suggest to unpack anything in /usr/local. You might mess up your system badly. Always unpack and build source pacakegs outside the directory tree where they are going to be installed.

Unless by chance the application was already there under the same directory name and you wanted to keep both versions I can't see any threat from unpacking in /usr/local. At most it would only clutter up /usr/local. (pause while I pull off a booklet created with Xsane, Gimp, Tex, psnup etc. for stapling) OK I'm back.

5. Unpacking it will (probably) create a directory with files in it. cd to that directory and read (using less) the README, INSTALL etc. files that are present. To get a list of files use the command

In case of GIMP plug-ins, we are usually talking about a single C file that needs to be compiled and installed. GIMP comes with a simple command-line tool called gimptool that helps you with this task. It has a nice man-page, read it.

You are correct in this particular case. I was just reacting to the "I can't do it without an rpm" plaint. I do think users of Linux should know about command line tools and not just rely on semi-proprietary thingies like rpm. All Linuxes have tar and gunzip. Not all rely on rpm for installation. And Gimp and its children do not come in rpm's so to use Gimptool as you suggest someone has to have used either
gunzip, bunzip2 and/or tar to uncompress the archive and create the directory containing Gimptool. Or do you know of another way to do it?

John C.

_____________

Hi,

John Culleton writes:

Using a terminal emulation such as xterm, gnome-terminal or similar is probably more appropriate if you are working on X window system.

Why more apropriate? The experienced Linux user uses whatever is handy at the moment. For commmand line use unless I need to jump right back into a graphic application I find the alternate console easier to read.

Users might want to follow an online HOWTO or use google to answer some questions while they are installing things. Of course you can use the console if you like, but I don't think it's a good suggestion for newbies (especially since you didn't tell them how to switch back).

I would not suggest to unpack anything in /usr/local. You might mess up your system badly. Always unpack and build source pacakegs outside the directory tree where they are going to be installed.

Unless by chance the application was already there under the same directory name and you wanted to keep both versions I can't see any threat from unpacking in /usr/local. At most it would only clutter up /usr/local.

Unless you examine the package beforehand, you can not know what files it will unpack. If the package doesn't have all files in a subdirectory, you could clutter up /usr/local with lots of files that shouldn't be there. Even worse, the package might include directories named bin or lib or share. If that is the case their contents will merge with the files you have in /usr/local and you will have a hard time to clean up afterwards.

Another point against using /usr/local is that you would have to have root priviledges. You shouldn't unpack and compile software as root. Only 'make install' needs root priviledges.

It is safe to use a dedicated directory in your home-directory to unpack and compile software. Do so as a normal user. When you are done compiling everything, become super-user and install.

Not all rely on rpm for installation. And Gimp and its children do not come in rpm's so to use Gimptool as you suggest someone has to have used either gunzip, bunzip2 and/or tar to uncompress the archive and create the directory containing Gimptool. Or do you know of another way to do it?

I was talking about the plug-ins and script that don't use an archive at all but ship as a single file. In the case of the psd_save plug-in, it is unfortunately distributed from the registry as a ZIP archive although it contains nothing of use but a single C file.

Sven

On 2003-05-09 at 1958.39 +0200, Sven Neumann typed this:

Hi,

John Culleton writes:

Unless by chance the application was already there under the same directory name and you wanted to keep both versions I can't see any threat from unpacking in /usr/local. At most it would only clutter up /usr/local.

Unless you examine the package beforehand, you can not know what files it will unpack. If the package doesn't have all files in a subdirectory, you could clutter up /usr/local with lots of files that shouldn't be there. Even worse, the package might include directories named bin or lib or share. If that is the case their contents will merge with the files you have in /usr/local and you will have a hard time to clean up afterwards.

Another point against using /usr/local is that you would have to have root priviledges. You shouldn't unpack and compile software as root. Only 'make install' needs root priviledges.

It is safe to use a dedicated directory in your home-directory to unpack and compile software. Do so as a normal user. When you are done compiling everything, become super-user and install.

debian opted to clean my /tmp directory for me everytime i reboot, which isn't very often. i like to unpack things there, when i can think about it. this way the source is around for a long time, but not forever ;)

maybe i don't use this directory properly. is there a traditional use for /tmp that i should be doing?

carol