FVWM: fvwm-crystal-3.7.1 released
Version 3.7.1 - Fvwm Crystal 3.7.1 is an important bug fix release. - Fix X failure at fvwm-crystal start when sh is dash (Debian and derivatives). I am sorry for that inconvenient which broke X startup on some distributions. I was very excited to release 3.7.0 which introduced fvwm3 support and didn't tested it on Debian. Being on a middle of a system update, virtualbox was not working. I learned the lesson and this lack of testing will not happen again. It also introduce some minor bug fixes and feature as well: - Use StartFunction with Test (Init) instead of the deprecated InitFunction in the Startup file of the preferences folder. - Add alsamixer launcher in the Startup file with support for the current Mixer preference setting. - Start FvwmMFL when running fvwm3. - Add support for FvwmPrompt (fvwm3 with golang support) and fvwm3 without golang into the FvwmMiniConsole. Fvwm2 and fvwm3 without golang are supported via FvwmConsole. As always, see ChangeLog for details. https://sourceforge.net/projects/fvwm-crystal/files/ Have fun! Dominique Michel
FVWM: fvwm-crystal 3.6.0 is out
Version 3.6.0 - Code name "Magic Star" You can download it from https://sourceforge.net/projects/fvwm-crystal/files/ Fvwm Crystal 3.6.0 is a big step forward. - Dependencies updated to >=fvwm-2.6.9 and python3. - A configurable button bar along with the Custom new recipe are providing a contemporary look. It have its own preference menu and can be placed on any side of the desktop. - Left click: menu or application launcher - Middle cllick: remove the button and redraw the bar - Right click: preference menu, a new button will be placed at the right of the clicked button - New Italian translation - Support for FVWM_*DIR at fvwm-crystal invocation, see 'man fvwm-crystal'. - Support for Icon and MiniIcon fvwm Styles for each application found during the application menu generation. - Support of automatic restart of urxvtc when crashed. - Silent the application database. This make the login shell (and fvwm-crystal logfile if any), to be less poluted by external applications. - Improved the systemd Exit menu with hibernate/resume support. - Screenlid suspend-hibrid support with preference - Cadence support into the Music menu and Music GUI key binding - Mouse velocity preference (default: system value) - The python scripts are updated to python 3. They was tested with python 2 and should work, but that's not officially supported anymore. - Update of the Fullscreen fonction to the new fvwm builtin function with workaround about non ewmh compliant browsers That update simplify this function and make it to work better. - Improved support of different button sizes into the recipes with preferences. - The ACPI applets will be shown only when the required hardware is found. - New window decorations Buttons-amigaos-Fullscreen and Buttons-amigaos-MiniIcon-Fullscreen. A left click on the second button will bring the window in fullscreen. The existing amigaos button models will now maximize the window. As always, numerous fixes, bugfixes and new applications and icons for the application menu. Most important ones: - The EWMH working area was reverted to its original function and improved. It should work fine with all recipes and with both the desktop manager and the new button bar when activated. - Fix support of svg application icons. - Temporary fix for the Font preferences applet crashing at launch with some colorsets (due to a fvwm bug). It can look uggly but should work with all colorsets. - Fix the media players styles. This also fix their icons at top layer after a recipe change bug. See ChangeLog for the details. I tested fvwm-crystal with fvwm 3. It mostly work and is usable, but that's not supported at that time. Anyway, that's a very good news for the future of fvwm-crystal. A big thank you to the fwvm workers for their dedication to fvwm and for their support! A big thank you to Star the dog and to the translators! With the new Custom recipe and its magic button, fvwm-crystal get a modern look and a terrific customizable multiple launcher. This imply most effort into its development will be focused into making it fvwm3 fully compliant. Which in turn mostly imply to update the fvwm dialogs to fvwm scripts at that time of writing. Translations, fixes and bugfixes will continue to be applied. New functions and other improvements will be accepted, but for my part, they will be part of a general reflexion about what I want to do with fvwm-crystal. I know what I don't want: a full rewrite would be a time consuming catastrophe because we will loose all the history including numerous fixes. Also, as fvwm-crystal has been more and more extended with time, I think a tooltip system must be added. Beside that, I would appreciate very much any ideas or contributions. Enjoy! Dominique Michel
FVWM: FVWM-Crystal 3.4.0 is out
A new fvwm-crystal release is out... just to begin the new year! This release brings new exiting features and many bug fixes: Support for hibernation/resume via pm-utils, The AlsaMixer mixer control can use any ALSA 'Volume' controls present in the system. New XDG menu (only with fvwm cvs at that time). Support for more image types with the application menu generation. Support for urxvtd (the urxvt terminal in daemon mode). New preference to start wanted applications in full screen. New UTF-8 Frison and Dutch translations - Thanks to Alwin for that! The remaining fixes and improvements are numerous, among others support for simple-mtpfs and arbitrary directories, updated German translation by Thomas Funk, updated French translation, And many other fixes I forget to mention, see the NEWS and ChangeLog files for details. https://sourceforge.net/projects/fvwm-crystal/files/ Have fun, and happy new year! Dominique
FVWM: Maximize and window location
Hi,
It is several Maximize function in Fvwm-Crystal. When a new window is
opened, a SetEnv made a variable with its window id and its
maximized state. 2 temporary files are also created, one with the
window width, the other with its height. I done this because I found no
other to do what I want and this to survive a restart. May be it is
simpler solution, but I didn't find it if it exist.
When a given Maximize function is called, I want the window to go in
that state. Only the SetEnv is updated. If the same Maximize function
is called 2 consecutive times, I want the window to return in its
original state and at its original location. The 2 temporary files are
used to get the original size.
It is a wrapper function:
DestroyFunc Window-Resize
AddToFunc Window-Resize
+ I Test (EnvMatch CurrentWindowState_$[w.id] $0) NS-Default
+ I TestRc (NoMatch) NS-$0
which is called by
Window-Resize argument
where argument can be one of
Maximize Minimize Default A100 H100 V100 VHgrow Hgrow Vgrow
The function that return to the original size is:
DestroyFunc NS-Default
AddToFunc NS-Default
+ I Maximize $[WindowWidth_$[w.id]] $[WindowHeight_$[w.id]]
+ I SetEnv CurrentWindowState_$[w.id] Default
And the other functions look like:
DestroyFunc NS-Maximize
AddToFunc NS-Maximize
+ I Maximize True 100 100
+ I SetEnv CurrentWindowState_$[w.id] Maximize
DestroyFunc NS-Minimize
AddToFunc NS-Minimize
+ I ResizeMaximize direction East 200p 60p
+ I SetEnv CurrentWindowState_$[w.id] Minimize
It is also the Fullscreen function that is called directly, and when
quitting the full screen style, NS-Default is called directly.
If I open a new window, place it in the middle of the screen and do
With NS-Minimize the window get very small and go to its left corner. I
try other direction like West, and to add fixeddirection, but I was not
able to get it to minimize around its right corner, which I would
prefer.
Beside that, NS-Maximize - NS-Minimize - NS-Minimize work as expected
and described above.
Another issue is with the FullScreen function. When returning to the
normal state, NS-Default is called with:
DestroyFunc Fullscreen
AddToFunc Fullscreen
+ I ThisWindow (State 19, !FvwmButtons, !MPlayer) Fullscreen-Stop
+ I TestRc (NoMatch) ThisWindow (!State 19, !FvwmButtons, !MPlayer)
Fullscreen-Start
AddToFunc FullScreen-Stop
snip
+ I NS-Default
Normally, it work just fine and the window is restored to its original
size and location. But sometime after a restart, only the window
borders and title style are restored and the window remain in its full
maximized state. When this append, I can call FulScreen several times,
the window never return to its original size and location.
I done some experiment. If I run
WindowID id FullScrenn-Stop
the problem is the same.
If I change NS-Default to
+ I Maximize False $[WindowWidth_$[w.id]] $[WindowHeight_$[w.id]]
the problem is the same.
If I change it to
+ I Maximize True $[WindowWidth_$[w.id]] $[WindowHeight_$[w.id]]
I get the original size, but the window is always at the top left
border of the screen, that even with a newly opened window or when
restoring NS-Default from another Maximize function than FullScreen.
And I want the location to be restored too.
At restart, it is a fullscreen recover function that apply again
the styles to the maximized windows:
DestroyFunc Fullscreen-Recover
AddToFunc Fullscreen-Recover
+ I WindowStyle !Title, !Borders, !Handles, Iconifiable,
ResizeHintOverride
+ I UpdateStyles
+ I WindowStyle State 19
+ I WindowStyle State 20
+ I Maximize ewmhiwa True 100 100
+ I WindowStyle !Maximizable, FixedSize
+ I UpdateStyles
DestroyFunc RecoverFullscreen
AddToFunc RecoverFullscreen
PipeRead 'for i in $[infostore.TmpDirectory]/fullscreen.19.*; do
wid=`basename $i | awk --field-separator . \'{print $$3}\'`; echo +
I WindowId ${wid} Fullscreen-Recover; done'
AddToFunc StartFunction I Schedule 1000 RecoverFullscreen
Is it possible to insure the correct location will be restored after
a restart and to not use more SetEnv or temporary files for that?
Best,
Dominique
--
We have the heroes we deserve.
Re: FVWM: Maximize and window location
Le Mon, 13 May 2013 21:46:43 +0100, Thomas Adam tho...@fvwm.org a écrit : On Mon, May 13, 2013 at 09:05:41PM +0200, Dominique Michel wrote: Hi, It is several Maximize function in Fvwm-Crystal. When a new window is opened, a SetEnv made a variable with its window id and its maximized state. 2 temporary files are also created, one with the window width, the other with its height. I done this because I found no other to do what I want and this to survive a restart. May be it is simpler solution, but I didn't find it if it exist. Sounds very over-complicated to me. Using a WindowID is bad here, not necessarily because it's only per-window, but for the fact that when FVWM restarts, the inherent use of WindowStyle to set the style of the window means it's lost on a restart. When FVWM restarts, its windows are reparented to the root window, and then reparented when FVWM starts again; in your case, the maximized state is recorded for windows across restarts, but FVWM doesn't record the state of all states across restarts for WindowStyle'd windows. They are lost anyway when fvwm restarts, it is why a added a function to restore them. The id is used only to apply the fullscreen styles on the full screened windows. It seems to me like you're reinventing a session manager here anyway; something I don't want to pedal as good advice anyway. When working on fvwm-crystal, I restart quite often and get tired of resizing the windows after a restart. Normally, it work just fine and the window is restored to its original size and location. But sometime after a restart, only the window borders and title style are restored and the window remain in its full maximized state. When this append, I can call FulScreen several times, the window never return to its original size and location. Then something about the window when it is recaptured is causing another style to match this window, most likely. I will try to increase the schedule time for the function that apply the fullscreen styles at restart and see what append. Best, Dominique -- Thomas Adam -- We have the heroes we deserve.
Re: FVWM: Maximize and window location
Le Mon, 13 May 2013 22:45:01 +0100, Thomas Adam tho...@fvwm.org a écrit : On 13 May 2013 22:41, Dominique Michel dominique.mic...@vtxnet.ch wrote: Le Mon, 13 May 2013 21:46:43 +0100, Thomas Adam tho...@fvwm.org a écrit : On Mon, May 13, 2013 at 09:05:41PM +0200, Dominique Michel wrote: Hi, It is several Maximize function in Fvwm-Crystal. When a new window is opened, a SetEnv made a variable with its window id and its maximized state. 2 temporary files are also created, one with the window width, the other with its height. I done this because I found no other to do what I want and this to survive a restart. May be it is simpler solution, but I didn't find it if it exist. Sounds very over-complicated to me. Using a WindowID is bad here, not necessarily because it's only per-window, but for the fact that when FVWM restarts, the inherent use of WindowStyle to set the style of the window means it's lost on a restart. When FVWM restarts, its windows are reparented to the root window, and then reparented when FVWM starts again; in your case, the maximized state is recorded for windows across restarts, but FVWM doesn't record the state of all states across restarts for WindowStyle'd windows. They are lost anyway when fvwm restarts, it is why a added a function to restore them. The id is used only to apply the fullscreen styles on the full screened windows. Well that's probably half the problem then, When working on fvwm-crystal, I restart quite often and get You're doing that wrong. See: https://plus.google.com/u/0/100692260234415059882/posts/YqzdH3jeAEg I use FvwmConsole and Xephyr too. I even added a Xephyr menu into the system menu. It look for the xsession files in /etx/X11/Xsessions. But when I am done with some changes, I move them to the svn, re-install fvwm-crystal and do a restart. tired of resizing the windows after a restart. Get BugOpts ExplainWindowPlacement and similar in to your logs so I can see what's happening, I will do that. or better yet, get a consistent application which shows your problem, and let me have steps to reproduce it. It will be difficult because it is a random issue that append from time to time. Dominique -- Thomas Adam -- We have the heroes we deserve.
FVWM: Fvwm-Crystal 3.1.12 is out in the wild !
Time for a new release that provide bugfixes and new features. - De-icoification of the full-screened windows have been fixed. They will appear now in full-screen without border or title. - Non wanted qjackctl and medias icons have been fixed. They should not appear any more as we can control those programs from the music button and menu. - Restrict Fullscreen to non FvwmButtons windows. It was possible to bring the buttons in full screen, and this is not wanted. - Unification of the desktop geometry. All the recipes have now the same 8 pages by 1 geometry. This fix the lost window issue with recipe changes. The Clean vertival recipe has been removed in the process, but it was the same than Vertical anyway. - The Icon-Launcher is now available in all the recipe through a new preference setting: Desktop manager - Thunar. This is the same setting than None, but with icons for all the mounted partitions. Clicking on those icons will open Thunar at the corresponding mount point. Simple and fast. - Some styles order fixes. - Last but not least, the font preferences have been fully rewritten. They are now under the form of a Font Selector which provide all the old settings into one dialog. Font styles support have been added, and the selected font is shown with its selected size and style. Of course, the example string can be edited, saved for later use and restored to its default value. This Font Selector is a FvwmScript with full xft and GetText suppot. That make it much easier to use than old style Fvwm font selectors using the core font. Xft support imply also full UTF-8 support. This was already the case with Fvwm-Crystal old font preferences sytem, but this new font selector is just the best. - Help needed with more translations, colorsets, decorations and whatever you can think about. Please considere to contribute. Dominique Note: You can ask you why I changed the version from 3.1.7 to 3.1.12. It's simple, bug fixes count for 3.1.8, and the added or changed features for the other steps. -- We have the heroes we deserve.
FVWM: FvwmScript and environment variables
Hi,
I am writing a font selector for fvwm-crystal with FvwmScript.
Most of it work, but I didn't succeeded to use environment variables.
In the config:
SetEnv panel_font Bitstream Cyberbit
In the script:
Set $SelectorFont = {xft:$[panel_font]:size=16}
but it doesn't work. I try everything I could think about, but nothing
worked.
Also thing like
Set $PanelFont = (GetOutput {echo $[panel_font]} 1 -1)
didn't work. This is with the last fvwm cvs.
I will change those variables to infostore, but I am waiting the next
fvwm release for that. (which will have EnvMatch that work with the
infostore)
Dominique
--
We have the heroes we deserve.
Re: FVWM: Binding keys with NoSymbol key name
Le Sat, 14 Jul 2007 06:52:37 +0100, Leo [EMAIL PROTECTED] a écrit : On 2007-07-11 22:58 +0100, Gautam Iyer wrote: I had the same problem a few days ago. You can use xmodmap to remap as follows. First find a keysym name to assign to these keys. Try doing grep -i audio /usr/share/X11/XKeysymDB [...] on fvwm startup. Finally, I have in my fvwm bindings key XF86AudioMute A N Exec exec amixer -q set Master toggle key XF86AudioRaiseVolumeA N Exec exec amixer -q set Master 2+ key XF86AudioLowerVolumeA N Exec exec amixer -q set Master 2- Many thanks. This greatly improves productivity ;) The only thing I am unhappy about is that the above just increases / decreases the volume, and gives you no confirmation or indication of what the volume is. I wouldn't mind a volume slider, like on my TV. Xosd has a nice volume slider, but that involves me writing a script that gets the current volume and feeds it to xosd. Should you, or anyone else on the list, know of a script / application that was designed for this purpose, let me know :) This will be nice but I don't know any program that does that. You can combine a call to xmessage with amixer: amixer sget Master | xmessage -timeout 10 -file - but this will be very verbose. You have to sort it with grep in the middle. amixer sget Master | grep Capture | xmessage -timeout 3 -file - and add further filtering with sed if needed. Dominique GI -- Dominique Michel -- N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me parvenir.
Re: FVWM: FVWM should be shipped with...
Le Tue, 13 Mar 2007 13:46:46 -0500, fREW [EMAIL PROTECTED] a écrit : I think that the best way to have that happen would be for someone to make a nice default theme. I think redhat used to include fvwm AND it was the default, but the theme that it came with was so terrible that everyone assume that's what fvwm had to look like. -fREW On 3/13/07, Dedeco [EMAIL PROTECTED] wrote: Hello, I know anyone can install FVWM if they want, but it seems like it is not shipped with many popular distros. In many places I use computers (linux), I have the option to choose wich WM I can use, but unfortunatelly the only distro I had it was SuSE. Is there any effort being made to convince the people responsible for arranging the linux distributions to include FVWM as an option of a window manager?? I think it would not be too difficult, since FVWM instalation requires less than 3 MB and is good, and has been here for much time. Kind regards. I think at for a package to be included in a distro, 2 things must be fulfilled: 1) Fill a polite bug report asking to include fvwm in the distribution 2) a developer must volunteer to maintain the package. With open distributions as gentoo or debian, it is quite easy to fulfill those 2 requirements for fvwm, because I think at someone that can configure fvwm will be able to maintain a fvwm package even if it will be a learning curve for that. Package management systems are not so hard to learn and fvwm is not so complicated to install. The most difficult think is in fact to install all the dependencies in the correct order, and it is a job that a package management system make very easy to do. If I look on gentoo, it can even be simpler to do an ebuild with the right dependencies, incorporate it in the portage tree and let portage do the job as to install the same program by hand. With commercial distributions, it is more complicated. As example Suse is very involved in kde development and it can be a political choice to not provide a decent fvwm version anymore. That even if yast is fvwm based. With those distributions, you have to look for an alternative rpm depository, or to provide one. Last, you can do you own install from the sources. Ciao, Dominique
FVWM: Locales problem in a menu script
Hi, I am on gentoo and I have done a menu script to have an alsaplayer control in the panel. I modified some fvwm-crystal scripts for that. The problem is at I use french locales: LANG=fr_CH.UTF-8 LANGUAGE=fr_CH.UTF-8 LC_ALL=fr_CH.UTF-8 and when I change to English locales, the volume and the speed control stop to work correctly. I have the following code: In Mixer-alsaplayer: DestroyMenu /Volume AddToMenu /Volume + 0 db% Mixer-Volume '1,0' + -3 db% Mixer-Volume '0,707' + -6 db% Mixer-Volume '0,5' + -12 dB% Mixer-Volume '0,25' + -18 db% Mixer-Volume '0,125' + -24 db% Mixer-Volume '0,0625' + 0 Mixer-Volume '0,0' DestroyFunc Mixer-Volume AddToFunc Mixer-Volume + I Exec exec alsaplayer --volume $0 In Music-alsaplayer: DestroyFunc /Music-generator AddToFunc /Music-generator + I DestroyMenu recreate /Music + I AddToMenu /Music '$[gt.Volume]' Popup /Volume The problem is at when I change to English locales, alsaplayer want to get . as decimal character, not a , I try to change the code as follow: DestroyFunc Mixer-Volume AddToFunc Mixer-Volume + I SetEnv x $0 + I PipeRead echo SetEnv y $(( $[x]/100 )) + I Exec exec xmessage x: $[x] + I Exec exec xmessage y: $[y] + I Exec exec $[A_Player] --volume $[y] DestroyMenu /Volume AddToMenu /Volume + 0 db% Mixer-Volume '100' + -3 db% Mixer-Volume '707000' + -6 db% Mixer-Volume '50' + -12 dB% Mixer-Volume '25' + -18 db% Mixer-Volume '125000' + -24 db% Mixer-Volume '62500' + -30 db% Mixer-Volume '31250' + -36 db% Mixer-Volume '15625' + 0 Mixer-Volume '0' But the shell output integer number in y, it mean only 1 or 0. I try this too: + I PipeRead echo SetEnv y $(( $[x]/100|bc-l )) but it work the same, I get only 1 or 0 in y. And it is even worse, because when I run $ echo 50/100|bc -l the shell output is always .5000 and that even when I use the french locales. Is it possible to get this script to work in any locale case? Dominique
Re: FVWM: Locales problem in a menu script
I see something new. When I start alsaplayer from a terminal, and issue the volume control command from another term, the program understand well both 0.5 and 0,5. But not when I start it from my menu. Dominique Le Thu, 28 Sep 2006 13:20:32 +0200, Dominique Michel [EMAIL PROTECTED] a écrit : Hi, I am on gentoo and I have done a menu script to have an alsaplayer control in the panel. I modified some fvwm-crystal scripts for that. The problem is at I use french locales: LANG=fr_CH.UTF-8 LANGUAGE=fr_CH.UTF-8 LC_ALL=fr_CH.UTF-8 and when I change to English locales, the volume and the speed control stop to work correctly. I have the following code: In Mixer-alsaplayer: DestroyMenu /Volume AddToMenu /Volume + 0 db% Mixer-Volume '1,0' + -3 db% Mixer-Volume '0,707' + -6 db% Mixer-Volume '0,5' + -12 dB% Mixer-Volume '0,25' + -18 db% Mixer-Volume '0,125' + -24 db% Mixer-Volume '0,0625' + 0 Mixer-Volume '0,0' DestroyFunc Mixer-Volume AddToFunc Mixer-Volume + I Exec exec alsaplayer --volume $0 In Music-alsaplayer: DestroyFunc /Music-generator AddToFunc /Music-generator + I DestroyMenu recreate /Music + I AddToMenu /Music '$[gt.Volume]' Popup /Volume The problem is at when I change to English locales, alsaplayer want to get . as decimal character, not a , I try to change the code as follow: DestroyFunc Mixer-Volume AddToFunc Mixer-Volume + I SetEnv x $0 + I PipeRead echo SetEnv y $(( $[x]/100 )) + I Exec exec xmessage x: $[x] + I Exec exec xmessage y: $[y] + I Exec exec $[A_Player] --volume $[y] DestroyMenu /Volume AddToMenu /Volume + 0 db% Mixer-Volume '100' + -3 db% Mixer-Volume '707000' + -6 db% Mixer-Volume '50' + -12 dB% Mixer-Volume '25' + -18 db% Mixer-Volume '125000' + -24 db% Mixer-Volume '62500' + -30 db% Mixer-Volume '31250' + -36 db% Mixer-Volume '15625' + 0 Mixer-Volume '0' But the shell output integer number in y, it mean only 1 or 0. I try this too: + I PipeRead echo SetEnv y $(( $[x]/100|bc-l )) but it work the same, I get only 1 or 0 in y. And it is even worse, because when I run $ echo 50/100|bc -l the shell output is always .5000 and that even when I use the french locales. Is it possible to get this script to work in any locale case? Dominique
Re: FVWM: Locales problem in a menu script
Le Thu, 28 Sep 2006 17:21:53 +0200 (CEST), Lucio Chiappetti [EMAIL PROTECTED] a écrit : On Thu, 28 Sep 2006, Dominique Michel wrote: Another way will be to test the locale in use, and sed the value to change the point against a comma when needed. But I have no idea where I can test the locale. I have never played with locales, quite hate them and happily stick to the C locale, but shouldn't be there an environment variable to test OR CHANGE, and could one not bracket such setenv in a subshell like (setenv =yyy ; command) ? I read something on the perl website when searching a solution for this script. The problem with the locales is at it is no one single normalisation but few normalisations. No matter, I find something that work when reading the files in /usr/share/fvwm-crystal. I done 2 sections in Mixer-alsamixer: DestroyFunc Mixer-VolumeFr AddToFunc Mixer-VolumeFr + I Exec exec $[A_Player] --volume $0 DestroyFunc Mixer-VolumeEn AddToFunc Mixer-VolumeEn + I Exec exec $[A_Player] --volume $0 DestroyMenu /VolumeFr AddToMenu /VolumeFr + 0 db% Mixer-VolumeFr '1,0' .. DestroyMenu /VolumeEn AddToMenu /VolumeEn + 0 db% Mixer-VolumeEn '1.0' .. And a test in Music-alsaplayer: Test (EnvMatch LANG fr_*.*) + I AddToMenu /Music '$[gt.Volume]' Popup /VolumeFr Test (!EnvMatch LANG fr_*.*) + I AddToMenu /Music '$[gt.Volume]' Popup /VolumeEn Thank you all anyway, it would have take more time without this discussion. Dominique I've used the trick for timezones, e.g. to know the time in Iceland one could (setenv TZ :/usr/share/zoneinfo/Atlantic/Reykjavik ; date) I do that (in sh syntax because of the SSI include directives) e.g. in http://sax.iasf-milano.inaf.it/~lucio/WWW/Personal/timezones.html !--#exec cmd=TZ=:/usr/share/zoneinfo/Atlantic/Reykjavik ; export TZ ; date-- Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
