Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lethosor]

I'm fairly certain either the dfhack or distro_fixes script is not the latest version (since that method of passing the DF directory between scripts was removed, unless I'm mistaken).
If by "bare binary" you mean libs/Dwarf_Fortress, that won't work because the scripts set up the correct library paths. Do you have libSDL installed?

[Machariel]

Well that is pretty dang basic -- you did not disappoint me there.  But now I get this:

Code: [Select]

/tmp/_MEInIEzaP/xdg-terminal: 364: [: x/home/ctc3d/action/df64/df_linux/dfhack: unexpected operator
/tmp/_MEInIEzaP/xdg-terminal: 367: [: x-x: unexpected operator

Any further clue?

I also was having this issue.  It was running just fine until today and it started happening.

Going into PyLNP.user and changing

Code: [Select]

"use_dfhack": true,

to

Code: [Select]

"use_dfhack": false,

as per lethosor's suggestion caused it to stop coming back with that error, but then I got:

Code: [Select]

[distro_fixes] [INFO] Checking whether any distro specific fixes are required...
/home/jack/Desktop/Dwarf Fortress/df_linux/df: 55: [: /home/jack/Desktop/Dwarf: unexpected operator
[distro_fixes] [INFO] OS: linuxmint
[distro_fixes] [INFO] ARCH: x86_64
[distro_fixes] [INFO] VER: 17.1
[distro_fixes] [INFO] DF_ARCH: 32-bit
[distro_fixes] [INFO] DF_BIN_LOCATION: /home/jack/Desktop/Dwarf Fortress/df_linux/libs/Dwarf_Fortress
[distro_fixes] [INFO] 32 bit df on linuxmint/64bit detected
[distro_fixes] [WARN] 32bit 'Dwarf_Fortress' on unhandled 64bit OS detected. If you get 'missing file' errors, please open an issue on Github: https://github.com/Lazy-Newb-Pack/Lazy-Newb-Pack-Linux/issues.
[distro_fixes] [WARN] Could not find a 32-bit zlib
[distro_fixes] [INFO] PRELOAD_LIB:
[distro_fixes] [INFO] LD_LIBRARY_PATH: /tmp/_MEIgRWcw0
[distro_fixes] [INFO] Done
./libs/Dwarf_Fortress: error while loading shared libraries: libGL.so.1: wrong ELF class: ELFCLASS64

from the terminal.  I also was getting this message when attempting to run df manually from the terminal.

I was able to solve this by running:

Code: [Select]

sudo apt-get install libgl1-mesa-glx:i386

as per this Ask Ubuntu post: http://askubuntu.com/questions/216367/steam-error-while-loading-shared-libraries-libgl-so-1-wrong-elf-class-elfcla where a number of other possible solutions for the same error message are posted.  Apparently it's a fairly well-known error.

Hope that helps.

[evoblade]

Hi. I'm on Manjaro XFCE. I downloaded the LNP and unzipped. I made sure all dependencies met. The Lazy Newb Pack launcher loads, but doesn't seem to do much. When I click "Play Dwarf Fortress" (either of the places you can click to start), I get a popup window that says "Not found: data/art/Phoebus..16x16.png"

and The popup terminal window has this:

[distro_fixes] INFO Checking whether any ARCH/distro specific fixes are required...
[distro_fixes] INFO OS: ManjaroLinux
[distro_fixes] INFO ARCH: x86_64
[distro_fixes] INFO VER: 15.09
[distro_fixes] INFO DF_ARCH: 32-bit
[distro_fixes] INFO DF_BIN_LOCATION: /home/irate/Downloads/DF_LNP_40.24/04024r3-x64/df_linux/libs/Dwarf_Fortress
[distro_fixes] INFO 32 bit df on ManjaroLinux/64bit detected
[distro_fixes] WARN 32bit 'Dwarf_Fortress' on unhandled 64bit OS detected. If you get 'missing file' errors, please open an issue on Github: https://github.com/Lazy-Newb-Pack/Lazy-Newb-Pack-Linux/issues.
[distro_fixes] INFO Done

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "adwaita",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "mist",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine",

(Dwarf_Fortress:8519): Gtk-WARNING **: Unable to locate theme engine in module_path: "mist",

Any ideas what I am doing wrong.

[lethosor]

Try replacing distro_fixes.sh with this version (click "raw" to download it more easily).

[isitanos]

I'm very confused as to what I'm supposed to use if I have a 32-bit system. The download page says to get the i686 version, but isn't i686 another (rare) 64-bit architecture, distinct from x86-64? Shouldn't it say i386 or simply x86?


Furthermore, in the so-called i686 download, the included Dwarf Therapist is compiled for x86-64:

Code: [Select]

$file ./DwarfTherapist
 ./DwarfTherapist: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=c494a991a142f5acb5022fba3f90d98fea01cd75, not stripped

Also I'm running Lubuntu (LXDE desktop) and Lazy Newb pack can't launch DF or run any utility. This seems to be related to the lack of the exo-open command line utility. You might want to use a more widely available program to launch applications, or list exo-open in the dependencies, i.e. sudo apt-get install exo-utils.

Still waiting for the "lazy" part of the pack   . I've got the newb part covered.

[lethosor]

I'm very confused as to what I'm supposed to use if I have a 32-bit system. The download page says to get the i686 version, but isn't i686 another (rare) 64-bit architecture, distinct from x86-64? Shouldn't it say i386 or simply x86?

i686 is 32-bit. From what I gather, it's an extension of the i386 instruction set, although I don't know enough about x86 architectures to be certain.

Furthermore, in the so-called i686 download, the included Dwarf Therapist is compiled for x86-64:

Code: [Select]

$file ./DwarfTherapist
 ./DwarfTherapist: ELF 64-bit LSB  executable, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=c494a991a142f5acb5022fba3f90d98fea01cd75, not stripped

That's definitely an issue (although it surprises me a bit, since the last time I asked Beautato, he said that the DT build was one of the few differences between the two packs).

Also I'm running Lubuntu (LXDE desktop) and Lazy Newb pack can't launch DF or run any utility. This seems to be related to the lack of the exo-open command line utility. You might want to use a more widely available program to launch applications, or list exo-open in the dependencies, i.e. sudo apt-get install exo-utils.

I rarely actually use PyLNP for gameplay - does launching utilities launch DF first? If so, the problem is probably that the xdg-terminal script uses exo-open to launch a terminal, although it shouldn't just use that (maybe exo-open is the last thing it attempts to use). You could try setting your terminal to xterm (or something else, like lxterm) somewhere in PyLNP's settings.

[isitanos]

I rarely actually use PyLNP for gameplay - does launching utilities launch DF first? If so, the problem is probably that the xdg-terminal script uses exo-open to launch a terminal, although it shouldn't just use that (maybe exo-open is the last thing it attempts to use). You could try setting your terminal to xterm (or something else, like lxterm) somewhere in PyLNP's settings.

Without installing exo-utils, here's the result of running ./xdg-terminal on the command line:

Code: [Select]

$ ./xdg-terminal
./xdg-terminal: 386: [: x: unexpected operator
Me@MyHostName:~/DF_LazyNewbPack_04024r3-i686$ nohup: redirecting stderr to stdout
nohup: failed to run command 'exo-open': No such file or directorySounds like there is an error in the script, which perhaps prevents it from running though all the options.


I found the option to change the terminal in PyLNP, and changing it to lxterminal does allow launching stuff. I'll use that as a workaround in the meanwhile.

[Pidgeot]

I'm very confused as to what I'm supposed to use if I have a 32-bit system. The download page says to get the i686 version, but isn't i686 another (rare) 64-bit architecture, distinct from x86-64? Shouldn't it say i386 or simply x86?

i686 refers to Pentium Pro and Pentium II-era processors, which came out about 20 years ago. Still 32-bit, just a little bit more advanced instruction set than the 386.

Also I'm running Lubuntu (LXDE desktop) and Lazy Newb pack can't launch DF or run any utility. This seems to be related to the lack of the exo-open command line utility. You might want to use a more widely available program to launch applications, or list exo-open in the dependencies, i.e. sudo apt-get install exo-utils.

The script uses exo-open because it believes you're using xfce, and that's the way you launch a stand-alone terminal when you have xfce. (It thinks you have xfce because there's a running process containing the word xfce.)

The script does have support for detecting LXDE, actually, but xfce is checked earlier, and it always uses the first match. You've already noticed the Configure terminal option; plain "lxterminal" likely works, but "lxterminal -e $" is the command that would be equivalent to the one normally run by the script on LXDE systems.

[isitanos]

i686 refers to Pentium Pro and Pentium II-era processors, which came out about 20 years ago. Still 32-bit, just a little bit more advanced instruction set than the 386.

Thanks for the refresher. I think i686 is unusual enough that it shouldn't be used to designate the 32-bit download. x86-64 vs x86 is better known... or just put 64 bit Linux vs 32 bit Linux.

The script uses exo-open because it believes you're using xfce, and that's the way you launch a stand-alone terminal when you have xfce. (It thinks you have xfce because there's a running process containing the word xfce.)

The script does have support for detecting LXDE, actually, but xfce is checked earlier, and it always uses the first match. You've already noticed the Configure terminal option; plain "lxterminal" likely works, but "lxterminal -e $" is the command that would be equivalent to the one normally run by the script on LXDE systems.

Thanks, I figured there was an argument to pass to lxterminal, but it does work without. You should check my reply to Lethosor above, in my environment the xdg-terminal script prints out an error. This said Lubuntu does by default use some stuff from Xfce, I have xfce4-notifyd and xfce4-power-manager running right now and they came with the distro.

[Pidgeot]

i686 refers to Pentium Pro and Pentium II-era processors, which came out about 20 years ago. Still 32-bit, just a little bit more advanced instruction set than the 386.

Thanks for the refresher. I think i686 is unusual enough that it shouldn't be used to designate the 32-bit download. x86-64 vs x86 is better known... or just put 64 bit Linux vs 32 bit Linux.

The iX86 monikers still gets thrown around a fair bit in my experience. The more newbie-friendly ones, like Ubuntu and Mint, tend to not bother since the few people that require pre-i686 support won't be using those distros anyway, and therefore don't care that it's really i686 - but many distros (Arch, Debian, Gentoo, openSUSE, Fedora...) still use them in their download names.

i686 *specifically* may be a bit rarer, especially compared to i386, but it's the most concise and accurate way of specifying the requirement - just x86 implies pre-i686 as well.

The script uses exo-open because it believes you're using xfce, and that's the way you launch a stand-alone terminal when you have xfce. (It thinks you have xfce because there's a running process containing the word xfce.)

The script does have support for detecting LXDE, actually, but xfce is checked earlier, and it always uses the first match. You've already noticed the Configure terminal option; plain "lxterminal" likely works, but "lxterminal -e $" is the command that would be equivalent to the one normally run by the script on LXDE systems.

Thanks, I figured there was an argument to pass to lxterminal, but it does work without. You should check my reply to Lethosor above, in my environment the xdg-terminal script prints out an error. This said Lubuntu does by default use some stuff from Xfce, I have xfce4-notifyd and xfce4-power-manager running right now and they came with the distro.

Hmm, in that case it would probably make sense to switch those two checks around... xdg-terminal is really just a slightly tweaked version of a pre-existing shell script, but I *did* have to tweak the xfce detection quite some time ago (in February). That's part of the reason it's checking for running processes; the old check didn't work reliably, and that was the best alternative I had.

It's not something I can fix right now, since I'm prevented from doing proper development and releases for another month or two, so for now, the "Configure terminal" workaround is the best (unless you want to modify the script yourself, of course!). Eventually, I should really just rewrite the script in Python, though, so it's a "proper" part of the launcher...

[sparr]

(stupid question removed)

[Pooky]

Hi there,

It seems I am getting the same error as many and I tried the different possibilities without success.

So I am on the latest Ubuntu version and here is what I get when I try to launch DF on LNP:

/tmp/_MEInIEzaP/xdg-terminal: 364: [: x/home/ctc3d/action/df64/df_linux/dfhack: unexpected operator
/tmp/_MEInIEzaP/xdg-terminal: 367: [: x-x: unexpected operator

Any idea what is happening?

[lethosor]

That's an issue with the xdg-terminal script bundled in PyLNP, which will probably have to wait for a new PyLNP release to be fixed. If that occurs when launching DF, try running the 'dfhack' or 'df' scripts manually (either from the command line or from whatever file manager you use).

[Ateya]

Just an FYI for anyone having a similar issue to me: When selecting graphic tilesets in PyLNP, characters/animals would show up as they're ASCII counterparts (a goose showing up as the letter "g"). Downloading and installing the newest version of PyLNP (over the top of the one included in the pack) and then reselecting the tileset fixed this issue for me. At the time of writing this the newest version of PyLNP is 0.10b and I am running Arch Linux x64 bit.

[Gebbeth]

Guys! I think I solved this “unexpected operator” error I started having when I updated my Kubuntu from 15.4 to 15.10. I have 64-bit system. I tried so many things, many of them were probably unnecessary, the important part goes something like this:

1. I downloaded and unpacked fresh LNP 04024r3-x64.zip,  so it shouldn't be corrupted.

2. I opened my terminal – Konsole, typed:

Code: [Select]

cd ~/[where my LNP is]
./startlnp
3. The PyLNP window would appear and I could change things, but after clicking PLAY, terminal would flash for a fraction of second and disappear, game would not launch and Konsole would give me the “unexpected operator” diss. So in PyLNP I clicked File/Configure terminal and in new window pasted:

Code: [Select]

xterm -hold -e
4. In Graphics tab I changed Print Mode to 2D and True Type Fonts to YES (I made sure I have my favourite font in 04024r3-x64/df_linux/data/art/ named as “font.ttf”, NOT “font.TTF” - it never worked for me, must be all lower case).
If I set other Print Modes or TT Font to NO, game wouldn't get past “Loading bindings from data/init/interface.txt” without any error, or I would have issues with 40th line in distro_fixes.sh (I didn't save exact prompt). 2D + TT YES was only option that worked for me.

5. Now after clicking Play a new xterm terminal would pop up (with dfhack) and lo and behold – Dwarf Fortress would launch! I generated world, embarked and played a while, tried out a few dfhack commands – everything worked!

6. Drawbacks and side notes:
a) I successfully updated PyLNP to newer 0.10b version, no problem here.
b) After quitting DF, I have to manually close xterm window (which is running dfhack) – it won't disappear on its own.
c) Upon launching xterm terminal and dfhack/Dwarf Fortress, PyLNP freezes completely, but everyting else works. Because of that, I can't start Therapist included in pack. I had to install it separately, which with available .deb file was very easy and good, because it's the newest version. So now I have to launch it on my own, but it works.
d) For reasons unknown, PyLNP won't launch by clicking icon, I have to start it from terminal. The good thing is that when xterm with dfhack and actual game is running, I can close terminal/konsole window which I used to open ./startlnp - PyLNP disappears, xterm and game stays.
e) I didn't bother with checking save files or going through my original tampered LNP files.
f) I tried various other things that Google suggested for specific errors. What I described above is what worked or at least didn't harm, below is what definitely or most probably didn't work on their own:
- after unexpected operator error - rummaging in scripts of startlnp or xdg-terminal, changing “==” to “=” didn't do anything,
- reconfiguring sh/bash/dash/whatevash with sudo sudo dpkg-reconfigure dash didn't do any difference to me,
- adding xterm -e in PyLNP, without “hold”, didn't work – xterm would flash and disappear,
- deleting libstdc++.so.6 and libgcc_s.so.1 from df_linux/libs folder, as suggested on Github didn't do anything to me,
- I also had some nohup error, without unexp. operator error, but due to the fact I have Polish version of Kubuntu some prompts are translated from English to Polish, this was some ridiculous magic spell “forwarding non-standard exit of errors to standard exit” - I couldn't even search for it, so I tried some other ways. Now it doesn't appear, so I guess it's ok now?

I hope my hazy babbling will help some of you. Cheers!