Using the Command Line

From Wine-Wiki.org
Jump to: navigation, search

This article provides a simple overview of the Unix / Linux command line with a bash shell and not the Wine CMD command line. It will therefore help you to run wine from the command line and is not meant to help you access a Windows-like command line under Wine.

Contents

Introduction

Experienced Wine users often find themselves resorting to the command line but users coming from the world of Windows will find this a little different at first. If you are new to wine there you may find some handy tips. You can also add your favorite commands that may be of help to others. To try any of these on the command line, open a terminal window and start typing.


Basic Terminal Commands

There is a wealth of information on the internet about the many commands and tricks that can be done via the command line. New users neednt try and learn them all, but rather will find a few commands will suit most if not all of their needs at first. When they grow in confidence they may wish to learn further commands and things such as wildcards and redirecting output. To help you type file names and directories use tab expansion to help you.

Reminder: Those new to Linux should not use these commands when logged in as root until you start to know what you are doing. At first, try experimenting in your user account (which is usually restricted in what it can do).


Tab Expansion

U. Bonnes [May 05]: If you have "Program Files" and "Programme" in your directory, you need to type Shift-P, Tab and at least 'm' or '\ '. With "Program Files" and "programme", either P and Tab or 'p' and Tab will suffice :-) Wine Archives

Basic commands:

Open a terminal and lets start:

ls

Firstly we consider how to find out what is in a directory...list the contents of a directory by typing on the command line.

ls

You may be accustomed to using a mouse, but this can be a handy tool. Lets do a little more this time.

ls -a

list the hidden contents (files starting with a "." are usually hidden. An example is .wine, where you will find the fake windows directory used by wine).


cd

change directory. This lets you move around.

After checking using ls -a to confirm wine has installed the .wine folder try moving across into your wine fake windows directory

cd .wine

We can type a path and change to the directory like so (remember to use the tab key so you will have the correct spelling. Another handy thing about the tab key is that when you have a space in the name, it will add the correct slashes so it can read the full name and not get confused by a space in the middle.

cd fake_windows/system32

or try the tab expansion when writing this example... (the tild "~" stands for the users home directory)

cd ~/.wine/fake_windows/program\ files


And now to go back up a level and return to your home directory keep typing

cd ..

until the command prompt says you are home. With the commands so far we have made no changes to the computer at this point, so you should be safe to experiment and have a look around. You probably can already see several shortcuts to the above commands, so perhaps try and experiment a little.


cp

copy. Obviously this will change what is on your computer so be reasonably careful. You could try copying an unimportant document file to get your feet wet.

cp filename1 filename2

rm

remove or delete. Be carefull with this as you dont want to remove important files. We can remove wine's fake windows directory using rm (or set your favourite file manager to show hidden files and then use the mouse)

rm is a little more compilcated and rather than explain, we will now explain how you can learn about these commands. Type

man rpm.

When you are finished reading all about the different ways you can use rm, type q to exit the help file.

rm -rf ~/.wine

This could be used to delete your old wine configuration and wine's fake windows but it would be best to read the help file so as to understand what you are doing and what your options are.

Further Reading


Least Privilege Principle

The Least Privilege Principle simply stated means a program should use the least amount of special privileges needed to do the task, and further that tasks should be organized to need the least amount of special privileges. This is analogous to the "only on a need-to-know basis" security restrictions in military organizations or spy novels. In the stories, when a character learns something they shouldn't know, you get a fast moving plot line. In a computer, when a program has privileges it doesn't need or is not designed for, you have a very fast moving security vulnerability that can often lead to a crashed or compromised system.

The least privilege principle is a general guideline to help minimize the potential damage of a mistake. If you have only granted limited permissions to a particular user, any programs run under that user ID will only be able to affect a limited portion of the system, and thus any mistakes made by the user or any malicious code run by that user will have a limited effect.

In Linux (and other Unix or Unix-like operating systems) the least privilege principle is primarily implemented in the form of file permissions and user IDs. Any running executable has a user ID which ultimately ties back to some authenticated user process (your login) or a special system account. The file system and the operating system cooperate to limit the possibility of things like someone using Apache to read your mail folders or a user-level game bug causing a system crash.

The major and obvious exception to this principle is the super-user or root account. Root always has permission to do anything to the system, and that makes it both very convenient and incredibly dangerous. There are many people who consider the existence of the root account to be a design flaw. It's still around because of its utility, but its use should be limited as much as possible.

In general, the only reason for a person to start a process with super-user permissions is to maintain or repair a system. And if you do need to maintain or repair your system, you should do as much as possible without super-user permissions.

The least privilege principle is one more way of improving the odds that your system will run reliably and securely.


Super User privileges

The superuser is a privileged user who has unrestricted access to the whole system; all commands and all files regardless of their permissions. By convention the username for the superuser account is root.

su
password:

However [J.McKenzie feb 09] if you saw a message like the following "You must be an Administrator to run this program" when attempting to run a program in Wine do not expect "Administrator to be the same as root" and try to run the program as root. [..] some new users think, incorrectly, that running Wine as root will give them more permissions. It does not and should not. [Do not run wine as root unless you are a wine guru - it breaks things. Stop. If you are reading this - You are not a wine guru ;-)]

Further Reading

How to tell if your terminal is user or root

Often your prompt will tell you. If it ends in a hash, it usually means root. But as this is configurable and you really forgot that you were playing with it, there is another way..

Vitamin [2011 feb] Run this in terminal. Code:

id -a

Sudo

The least privileges principle would suggest you use "sudo" instead of "su" for the changes. Specifically, instead of using "su" to get a root shell, you can as a normal user do "sudo chown [your_user_name] FILE" and only have root authority for the one command. (You may need to install or configure sudo if it isn't standard in your distribution.) What sudo does is allow a user to run a single command with super-user permissions. Sudo is very configurable as to which users it will allow to run what commands. When you run sudo, you are prompted for your user account login password before the command is executed. This authentication is to limit the danger of stepping away from your keyboard for "just a bit". Typing in your password for all sudo commands would be annoying, so the sudo program starts a timer. If you use sudo again within the time limit (default of about 5 minutes) you are not prompted for your password. Depending upon how sudo is set up on your computer, you provide either your password or the root password.

sudo [command]

S. Brown: the whole point of using sudo is that it removes the necessity of anyone other than root knowing the root password. [...] Using a properly configured sudo, the non-root users are allowed to execute a (possibly limited) number of commands with root privileges, but authenticating using their OWN password.

M. Meissner: sudo has more features that are good ... like keeping authentication for some time or specific roles. Thats why openSUSE keeps it secure this way (by using the root password). You can of course change this for yourself.

Running Wine as a User

Sometimes people dismiss the warning about not running wine as root as just a "security precaution".

Well, it is a "security precaution", but it's also a lot more. And it isn't just Wine that you shouldn't run as root or superuser, it's any program. On any Unix or Linux computer system, a process running with root (uid=0), (or in MS-Windows a process running with administrator privileges) has unquestioned authority to change the system. Execution privileges directly affect program functionality, and giving a program too many privileges means you may be giving it more than it was designed for. When running wine, you are often running software where the code is not open to critical review, you have a big installation file that you can only hope is well behaved. For example a badly behaved program mentioned on the mailing list apparently tested to see if a file exited by trying to delete it! If deleting failed it seemed to assume that the file existed.. but if you were running wine as root it might successfully delete something..

File Permissions

A Linux (or Unix) file system keeps permission and ownership information for each file or node on the disk. The basic permissions for a file are read, write, and execute (for a directory, the execute permission bit is used for search permission). Permissions can be set differently for the user who owns the file, the group for the file, and for all others.

Under normal circumstances, everything in a user's home directory is owned by that user, and things generally work reasonably well without worrying too much about this. If you need to share files with another account on the system, you can set up or use an appropriate group. If you want to grant permissions to everyone on the system, you can use the "other" permission bits.

If you have made the mistake of running wine as super-user, you may have files in your home directory that you cannot access. This happens when the running program saves configuration data or any other file or directory as root. Many programs save some state information between runs, so this is very common. If wine was started as root, all the files or directories it created will be owned by root and will generally not be writable by any other user, and possibly not readable. The practical effect of this is you will be unable to run that particular program as your normal user account because it will not be able to read or write its own configuration information.

If you have ever made the mistake of running wine as root and are now having permission problems running as a normal user, this is probably what happened.

You should not need to be superuser to look for the problem files.

 $ cd ~[your_user_name]
 $ find . \! -user [your_user_name] -print | xargs ls -ld

This will traverse your entire home directory and provide a long listing of all the files and directory nodes that are not owned by [your] account.

Unless there is something very peculiar going on, you should be able to do a chown to fix this. (You may have to also use a "chgrp" command if the group ownerships aren't correct.) I don't recommend using the "-R" flag until you have a sense of what it will change.

NOTE: this is a repair operation, and you will need to be super-user (or preferably use sudo) in order to do the chown/chgrp commands.

For each file in your home directory that is owned by root, you will need to change the ownership to your normal account.

CAUTION: This is a repair operation. You need to be very sure you know what you are doing. You can very easily damage your system if you make a mistake.

For each file with the wrong ownership in your home directory, you need to change the ownership back to something sensible, which in this case means your own account and default group.

sudo chown [your_user_name] FILE
sudo chown [your_user_name]:[your_login_group] FILE

If there is only a small number of files, just do them one at a time.

If there are a lot of files, read the man pages for the "find" and "xargs" commands that were used above to determine the extent of the problem.

WARNING: Do _not_ change the ownership of any files outside your home directory. In particular, "chown -R [your_user_name]:[your_login_group] /" is a very bad idea and will generally require you to reload your system in order to make it stable again.

Wine Archive

Fixing your wine if you ran it as root

One way is to delete it completely as root but you can try and fix it. A. English recommended fixing wine after installing as root: sudo chown -R user:user .wine However this would not fix the wine directory if you used a different WINEPREFIX. J. McKenzie: Also, if the user is on an alternate wine prefix this would change to: sudo chown -R <username>:users $WINEPREFIX

Vitamin noted: You forgetting all the files created under ~/Desktop, ~/.config and ~/.local. Those will be a bigger [problem] and source for lots of issues.

Backing up your Wine directory

Sometimes you need to check the latest wine version but dont want to loose all your installed programs. There is a way. Rename it, say to .wine.old and then try the latest version. If you wish to use the old version, reinstall the older version of wine and then restore .wine.old back to .wine

mv ~/.wine ~/.wine.old

[wine user Jul 07]is a short version of move command[..] it is better style; if you execute it under [your user name] your shell will automatically replace "~" with your current home directory "/home/[your username]".

What does ~ mean

A user asked jun 08: What does ~ mean? cd ie. "~/.wine/drive_c/" P. Johnson: ~ is your home directory, probably something like "/home/[your name]"

Checking What Shell you are running

how can I check exactly which shell user I am using ? A. English [type]:

echo $SHELL

Basic Wine Commands

WINEDLLOVERRIDES

This command allows for the temporary overriding of builtin dlls and is currently [July 05] commonly used with Wine for quickly overriding dlls without needing to run winecfg.

Here is an example for overriding the builtin dlls for comctl32 and commctrl32:

WINEDLLOVERRIDES="comctl32=n,b;commctrl=n,b" wine myprogram.exe

several excellent examples are provided with the Wine Man Page

Further Reading

Wine dll override tips and tricks

Some recommend different syntax with WINEDLLOVERRIDES, but enclosing the list of dlls with "" and seperating each dll with a semicolon ';' may be the safest option. Care need to be taken when using this command, as miss-spelling are not uncommon.

Remember to write WINEDLLOVERRIDES in UPPER case, with two 'R's. ;-)

To set application specific overrides since June 2005 you can use winecfg

D. Clark: [Dec 05] Wine recently changed from using system to system32 as the default directory for DLLs.

R. Klazes [Sept 05]: Try without the extension: [instead of writing "oleaut32.dll"="native" ], use "oleaut32" = "native". J. Hawkins [Sept 05]: To override .ocx files you have to provide the .ocx extension.

J. Earnst: [Oct 05] Don't copy blindly all your dlls in this directory. Using native dll should only be used when builtin dlls don't work for a particular application. In some case native dlls help, in other they will do more bad than good. BTW if you want to use a particular native dll with one or more applications, you have to set it using winecfg after copying the native dlls.

Anon: sometimes you only need to copy a dll over to the directory where the software resides. If you copy the dll to system32 it may (or may not) affect other programs. To check which dlls from Windows (and not from your software) that can be copied from a Windows system and overidden using winecfg, and look thru the drop down box - it lists what you are permitted to override.

Further Reading


Troubleshooting WINEDLLOVERRIDES

a programmer noticed [July 05] that for wine20050628 the command line WINEDLLOVERRIDES was not always being heeded. (This was confirmed using WINEDEBUG= loaddll):

env WINEDEBUG= loaddll WINEDLLOVERRIDES=msvcrt=n /spare/bon/wine-realclean/wine/wine Galep32.exe
trace:loaddll:load_builtin_dll Loaded module L"kernel32.dll" : builtin
trace:loaddll:load_builtin_dll Loaded module L"c:\\windows\\system\\msvcrt.dll" : builtin

Also explicitly requested, msvcrt is loaded as builtin. native msvcrt.dll is available in the system directory and the application directory (where Galep32.exe resides)

A. Juliard: If it's in the app directory you have to use *msvcrt in the environment overrides (though that is not completely consistent with the registry way, so it should probably be fixed). [A Patch was apparently made to cvs] Wine Archive


err:thunk:_loadthunk(commctrl.dll,Cctl1632_Thunkdata16,comctl32.dll): Unable to load "commctrl.dll, error 2
err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting. ^^^^^^^^^^^^^^^^^^

Unable to load commctrl.dll. This is likely because the dll is missing (or has been accidentally renamed). Check this native dll has been copied across to the \Windows\System\ directory. Apparently the Win98 Comctl32.dll must always be accompanied with commctrl.dll.

Anon [July 05]: comctl32 and commctrl (just like some other DLLs, e.g. setupapi and setupx) are 16/32 DLL combinations that should always be loaded either [both] *fully* natively or *fully* builtin, but no mixup. [update 2008] comctl32 is a special case and no longer easy to override. Perhaps winetricks is the best way.

List all current Wine processes

ps -ef |grep wine

Kill troublesome Wine processes

Sometimes InstallShield doesnt play nice and leaves you with the wine-preloader stuck. Then you need to kill it (With great regret, of course)

One method designed just for this is:

wineserver -k

If this doesnt work, then we get a bit more ruthless


Now for a caution: killall wineserver is a little too ruthless and is a last resort. Vitamin [Sept 09]: DO NOT kill server like that, unless you ok with corrupting Wine's registry. If you have to kill Wine, try 'wineserver -k' first. It will force terminate all Wine process and wineserver will gracefully exit. If that doesn't work, find the process that hung (most likely would be the name of the windows application) and kill it with 'kill -9 <pid>' or 'killall -9 app.exe'.

[Disclaimer: No bits are hurt in the killing of this process. Computers are NOT people.]

K. Ober: Make sure that when you kill them they do in fact get killed. Sometimes for me SIGTERM doesn't do the job and -9 (SIGKILL) is needed. Wine Archive

Peter: A reboot is hardly ever needed on Linux is you know what to kill/restart. If you dont, it can often be the quickest solution on a desktop system.

Another user offered his tip [Nov 05]: pgrep wine|while read p; do kill -9 $p ; done;


M.McCormack [Nov 05]: "killall -9 wine-preloader" works for me every time, however some older kernels have a bug which causes zombie processes (a placeholder for the process return code) to never be removed in the kernel. I think this was fixed around Linux 2.6.7 (ie. the unpatched Linux kernel). F. Gouget: Besides the zombie processes mentioned before, some processes may be stopped (e.g. by the debugger) and won't die until you send them a CONT signal.


M. Bostick [Nov 05] gave an example to bring a misbehaving Wine into line wine archive:

killall -9 wine

killall -9 wineserver

killalll -9 wine-preloader

Getting fancy with the command line

Keep in mind that this is a wiki, so if you try suggestions, you do so at at your own risk. If you spot a mistake, or think of a better method you are welcome to correct the examples..

Testing wine with a cd or dvd image

Copy the disk image to the hard drive

You might copy a dvd or cdrom to the hard drive. This will enable you to test your favorite software with each wine upgrade even faster, but it may not work with some copy protection. Here are three methods of doing this. Keep in mind that this is not a complete solution as Winehq Bugzilla entry 21674 Mounted ISO image is not enough to emulate CD-ROM device. It does not respond to most CD-ROM specific SCSI commands.

Using a Mouse

First copy the dvd or cd to the drive using the mouse - right click on the dvd icon on the desktop (it looks like a box with a cd poking out) and select the option to copy disk (dont forget to put he cd in the drive first!). Change the copy disk from cdrom to file image and click ok. Then browse to where you want to save it in your home folder but dont forget to write down the name. It will be something like xxxx.iso.

Using dd

Otherwise use dd. Here are two commands in one line. It first Unmounts the drive, and then copies it to the OutputFileName.iso. You might want to change the name to something you will recognise, and you might want to keep the .iso on the end of the file so you recognize it easier.

sudo umount /dev/[your_cdrom] ; dd if=/dev/[your_cdrom] of=OutputFileName.iso bs=1024
Using cat

Here is it broken down for a cd, but this time using the command cat. We log in as root using the command to switch user (su)..

su

(type the password for your root user) (if you have more than one cd player, check which device you have the cd in) - unmount it.

umount /dev/cd

Exit from superuser and carry on as a normal user..

exit

Now you can copy this image to the hard drive. Where you copy it is up to you. Perhaps into your home dir, (if you do copy as a root, you might want to change the ownership using the chown command - type 'man chown' to see how to do that). Change [image-name] to the name of the dvd or cdrom or just call it something like msoffice-image.iso

cat /dev/cdrom >/home/[yourusername]/[image-name].iso

Now that is it on the hard drive we can tell linux to pretend this file is a real cdrom. You do this by mounting the local disk image (see below)

Further Reading

Mount the local disk image on the computer

Now it is time to mount this file and get linux to pretend that it is really in fact a cdrom. You will need to be a root user again by typing su and your password. Linux will let you mount the file as a cd or dvd but we need to tell linux what name will represent this disk. We do this by adding a directory for the cd image in the media folder. You might use the original name for the dvd [image name] or cdrom [image name] or just call it a name that you will recognize such as "OfficeCD". Call it what you like, and use it for the examples here, but dont add the .iso bit - it can get confusing when you look at it later.

mkdir /media/[image name]

and now we can mount the file as a type(t) of an iso or cd or dvd under this directory. Hint, use tab expansion to make this easier to type:

mount -t iso9660 /home/[your-user-name]/[image name].iso /media/[image name] -o loop

remember to subsitute the name of the disk for [image name]

After you have created the folder, you dont need to re create it again. Next time, just mount the file as an iso and wine will find it.

Using a wine testing folder

If you already made a test folder, now is the time to delete it again and start from scratch. We can call it .wine-test for this example, but in time you might give each test folder a different name. The command export will remember setting until you close the window, so if you close the terminal window, type the export WINEPREFIX=~/.wine-test line again.

Make sure you are a user... and no longer as a superuser. The best way is open a new terminal window. Check that it has a $ on the end of the text. Lets create a wine testing folder. Set the folder for wine to be in your home directory (~) and call it .winetest by typing (you should be able to cut and past this command):

export WINEPREFIX=~/.wine-test

now get wine to set up a fake windows

wineboot

You will see some messages about wine setting up under the folder .wine-test. Now wine will have recognized your pretend cdrom we set up earlier and made it visible under wine. Lets run it. Most installations run setup.exe so run that. Check using the tab expansion, to make sure you type it correctly

wine /media/[image name]/Setup.exe

This will run setup and install it under the .wine-test folder. Because you have a dual wine setup you can test away and try all sorts of things under .wine-test without messing up your other wine folder (normally called .wine). Winetest will be helpful for this.

And finally when you have finished, delete your test folder...

rm -rf .wine-test

Rapid testing using Winetricks

Use winetricks to change your wine settings quickly - such as using a native comctl32.dll. Be aware you may need a Windows license for some of the tests. eg:

winetricks comctl32

Scripts

A script is probably of most use to Wine users who can write BAT files on Windows and might want to add shell scripting to their skill set. It is much like a bat file, but it is much more powerful. Even if you have never heard of a bat file, never fear. A script is a small text file which can automate repetitive tasks. While they can be powerful, start out small and you will eventually wonder how you ever did without them. For a bash script-what we are referring to here, the very first line should be !#/bin/bash. This tells the computer that it is a script, it runs upon bash. If a line starts with a # then it is merely a comment. Nothing is run on that line, but it helps you remember what you were doing. Sometimes a # is used to add a comment at the end of the line. If you used basic on windows, you may also recognize the group of commands: if, then, else and then closing with fi.

To allow a script to run, you need to tell the computer that you give it permission to run using chmod. To learn more about chmod, open a terminal and type man chmod, which will bring up the chmod manual. Yes, you will eventually get used to reading these, but in brief, the letters rwx refer to Read, Write and eXecute, from which we will want to change read and execute. An example with the file called compilewine may help.. you would type:

chmod uga+rx compilewine

and to run it:

compilewine

Another protection for Linux is that just any script will not run unless you put it where scripts are searched for, or you specifically tell the computer you want it to run by providing a) it's path as well as the file name or b) when you are in the directory where the script is located prefix the name with a ./ so in this case you would type ./compilewine to select a script called compilewine to run.

Adding it all up - testing wine using scripts

By making a script up you can automate a lot of the work in testing each release of wine. Feel free to add an example here.


ps

M. Gregorie: Login to the user, start a terminal window and run "ps". This should show two processes - the shell as the first line and itself (ps) as the second.

Mar 09 a user asked: [..]if I start my service named "app" should I then see app.exe in the "ps x" -list?

M. Gregorie:Yes, if you're logged in as the same user.

ps -u user

shows all processes for 'user', and

ps -ef

shows all processes on the computer. I find

ps -ef | grep progname

a useful command. It lists all processes and filters that list with grep to show [only] the process(es) you're interested in. It produces one or more lines. One is the grep process itself and the others are the processes you wanted to know about. If you use it a lot, write a small script:

#========start of filterps script file =========
#!/bin/bash
ps -ef | grep $1
========end of filterps script file =========

Put it in the search path and make it executable:

cp filterps /usr/local/bin
chmod uga+rx filterps

and to run it:

filterps app

(/usr/local/bin is usually [in] your the search path.)

ps version 2

Now for a more elaborate version with a help display and extra filtering to remove unwanted lines from its' output

#!/bin/bash
#
# filterps - filter process list
#
if [ $# -lt 1 -o "$1" == '-?' ]
then
echo "useage: filterps procname"
exit 1
fi
if [ "$1" == "grep" -o "$1" == "filterps" ]
then
echo "Error: you can't filter on grep or filterps"
echo " and expect anything useful"
else
ps -ef | grep -v filterps | grep -v grep | grep "$1"
fi

RPM commands

Red Hat, Mandrake and Mandriva users have installation files with the suffix .rpm. Each software package consists of an archive of files along with information about the package like its version and description. When installing an RPM take care to select for your version of Linux and processor type.

As an example, wine-0.9.4-mdk.i586.rpm refers to the Wine version 0.94 (wine-0.9.4) Installation file for Mandrake (mdk) system with Intel or AMD processors.

Commands for RPM require root or in other words, Administrator privleges. Either use su or sudo (see above for more information) for the following rpm examples.

List Wine versions installed

rpm -qa | grep wine

Uninstall Wine

rpm -e $(rpm -qa | grep wine)

or

rpm -e [wine rpm name]

Further Reading

Man rpm

Yum Commands

Red Hat Fedora users can use Yum on the command line. It can be handy and sometimes easier than the graphical tools.

List Wine Version Installed

As a user try typing in a terminal window...

yum list wine

You should see something like this:

Installed Packages
wine.i386                                1.1.5-1.fc8            installed       
Available Packages
wine.i386                                1.1.5-1.fc8            updates-newkey  

(Wine 1.1.5 is installed, and 1.1.5 is available from the updates-newkey repository.)

The rest will probably need to be run as a root or superuser.

Enable a repository

Check what repositories you have listed by typing

ls /etc/yum.repos.d/

The latest version of wine might be via the updates testing.Using your favorite editor, or try vim and edit the repository config file

vim /etc/yum.repos.d/fedora-updates-testing.repo

in the file you will see two line like

enabled=0
gpgcheck=1

change the enabled line to read enabled=1 and the repo will be available to be used. In vim you could type I for insert, navigate using the arrows move over to the line and change it by deleting the 0 and typing a 1 (yes, plenty of ways, but this will do for a tentative newbie - if you can explain a better or safer way - go for it). Escape out of insert by pressing esc, then save it by typing wq and pressing enter. Dont change anything else unless you know what you are doing. If you make a mess - dont save it. Type q for quit and add an exclamation point like so: q! and press enter. This will quit without saving your mistaken changes.

Install Wine

To install wine for the first time:

yum install wine

Update Wine

When you want to go and update to the latest wine:

yum update wine

Extracting Icons

B. Vincent: [Jun 05] Someone replied to me off list with info on the icoutils package: http://www.nongnu.org/icoutils/

Anyway, it's really cool. It can generate lists of resources, extract those resources from dll's, convert .ico files to png, etc.

Links

Wine Links

External Links

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox