Not every Linux machine is a webserver in constant need of security patches. I still have an old box with Slackware 11.0 just for fun. It doesn't talk to the hostile Internet, it doesn't need any updates.

Oh good grief. Get over yourself.

There is no need to be upset and get so aggressive.

They have every reason to be upset and as aggressive as you were in your response.
FYI the latest security update to Slackware 13.0 is from 3/27/2014 for OpenSSH, so it
can hardly be characterized as ancient. Also, Slackbuilds are simply shell scripts to build *.tgz packages from source, not the *.rpm nor *.deb package that you must be used to.
Anyway, you could easily have typed echo $DISPLAY in an xterm before posting. You would have obtained a :0.0 and you would have understood what is wrong with olwm/olvwm in that version of XView.

Now, to return to the original point of the thread, since you are not the person who wrote the script and tries to maintain the XView/OpenLook package you were not asked to reply.

Given the nature of the bug, I think without delving pretty deep into the xview code, this workaround is as good as it's likely to get.

I looked into the part of the code for both olwm and olvwm that opens the display. There are two ways that the DISPLAY environment variable will be set: either using a variable from rdb (Xresources/Xdefaults) or the defaults used by server. I suspect the possibility of a typo in either any possible system Xresources or a user one. If you confirm that you are sure it is neither of these, I would double check in your .xinitrc/.xsession that nothing that runs before the window manager is mangling DISPLAY env variable on you.

I have no idea what this has to do with anything. So?

And sorry, it is still ancient. And why would you take that as offensive? It was released 5 years, shipped with 2.6 kernel, etc. It is ancient, end of story.

13.0 isn't ancient and it's still supported for security patches but SlackBuilds.org scripts officially support only full installations of the latest Slackware stable (ATM 14.1).

I just tested xview on a slackware-14.1 virtual machine and was able to launch applications from the menu and have no need of the -Wfsdb command line option (just launched it with this xinitrc), so regarding directly edorig's question, I think there's a dedicated FAQ: I don't have a 32bit host with a 13.0 full install around to test OP's problem (and probably, who knows, neither Tomasz does).

@moisepedro: Please keep to the topic.

The only thing I did was politely ask OP why was he using sucn an old Slackware version. Then, for absolutely no reason, some people got really offended by that.

@moisepedro: Please, if you don't have constructive help to offer the original poster, keep further opinions out of this thread. That includes defense of your previous replies.

Thank you,
j_v

Ok, I am sorry for derailing the thread a bit. Nobody won't see no further posts from me.

@edorig: Ok, I've got a full 13.0 vm running with xview slackbuild installed. I am seeing the error you are talking about. The display environment variable is set properly in the shell environment, so I believe it is perhaps in the window manager's code for the menu. If it is, I should have something soon.

There is a fix in trunk: http://code.xenu.tk/repos.cgi/xview/info/1d21c3c976. I am working up a patch to the slackbuild that incorporates Tomasz's fix for this issue. These changes were made just yesterday, so perhaps he can be persuaded to incorperate this fix into his slackbuild.
I'm building the package now in the vm... I will post after I have tested.

Cheers

I've confirmed that the upstream fix works when applied to the current slackbuild. I've uploaded a patch to my github account: https://github.com/jvvv/slackbuilds/...rary_fix.patch.

In the top of the xview slackbuild directory:
I apologize if I'm stating the obvious about how to apply the patch.

Cheers,
j_v