Lazy-Newb-Pack / Lazy-Newb-Pack-Linux

A Lazy Newb Pack for Linux
http://lazynewbpack.com/
150 stars 12 forks source link

xdg-terminal: 364: [: x/home/arnaud/04024r3/df_linux/dfhack: unexpected operator #7

Open gronono opened 9 years ago

gronono commented 9 years ago

Hi guys,

I tried using LNP 04024r3 (downloaded on http://www.lazynewbpack.com/linux/#download). When I click on "Play" button my terminal shows me the following : arnaud@arnaud-portable ~/04024r3 $ ./startlnp /tmp/_MEIivTsik/xdg-terminal: 364: [: x/home/arnaud/04024r3/df_linux/dfhack: unexpected operator /tmp/_MEIivTsik/xdg-terminal: 367: [: x-x: unexpected operator nohup: redirection de la sortie d'erreur standard vers la sortie standard

Dwarf Fortress seems to work but it's not cool, isn't it ?

gronono commented 9 years ago

I tried #8 but my changes do not seem to be taken into account. It's always the old file is used. I don't understand where /tmp/_MEIivTsik/xdg-terminal come from.

Bakita commented 9 years ago

i have the same problem, only can run df directly i'm in ubuntu 15.04 with gnome /tmp/_MEIYpN1AK/xdg-terminal: 364: [: x/home/bakasa/DFL/df_linux/dfhack: unexpected operator /tmp/_MEIYpN1AK/xdg-terminal: 367: [: x-x: unexpected operator nohup: se redirige la salida de error a la salida estándar

Doyan commented 9 years ago

I seem to get something similar:

Traceback (most recent call last): File "/usr/bin/gnome-terminal", line 3, in import string File "/usr/lib/python3.4/string.py", line 49, in from collections import ChainMap File "/usr/lib/python3.4/collections/init.py", line 11, in from operator import itemgetter as _itemgetter, eq as _eq ImportError: dynamic module does not define init function (PyInit_operator) /tmp/_MEI5KTfr5/xdg-terminal: 305: [: xopenbox: unexpected operator /tmp/_MEI5KTfr5/xdg-terminal: 402: [: xxterm: unexpected operator /tmp/_MEI5KTfr5/xdg-terminal: 409: [: x/home/doyan/dwarf.fortress/04024r3-x64/df_linux/dfhack: unexpected operator nohup: redirecting stderr to stdout

camconn commented 9 years ago

I looked into this problem, and it appears to be a problem with pyLNP.

I'm looking into a fix now.

lethosor commented 9 years ago

Wasn't this fixed in #8 / b0038304e6c1cfc63fa8e30d16a5a7e8eadd7672?

camconn commented 9 years ago

@lethosor The copy I got from http://www.lazynewbpack.com/linux/#download has this issue. It has to do with the precompiled version of PyLNP using its own copy of xdg-terminal.

lethosor commented 9 years ago

Ah, that would explain why the problematic script is in /tmp. @BeauBouchard, I can't find anything in this repo that references xdg-terminal, so I assume PyLNP is the only thing that uses it - is there a reason why it's in this repo?

camconn commented 9 years ago

@Lethosor

You're spot on.

Unfortunately, I haven't been able to get PyLNP working on Linux so far.

Patching the problematic script in /tmp works, but then it causes even more errors to sprout from PyLNP.

Ugh

robkau commented 9 years ago

Getting hit by this issue as well.

quicksketch commented 9 years ago

I'm running into this issue as well Ubuntu 15.04, fairly clean install (just from a few days ago) but I do have a couple versions of Java installed.

Output for me:

nate@natebuntu:~/Downloads/04024r2-x64$ ./startlnp 
/tmp/_MEI90M05u/xdg-terminal: 364: [: x/home/nate/Downloads/04024r2-x64/df_linux/dfhack: unexpected operator
/tmp/_MEI90M05u/xdg-terminal: 367: [: x-x: unexpected operator
nohup: redirecting stderr to stdout

EDIT: I realized I was using r2 but r3 was available from http://www.lazynewbpack.com/linux/#download. Trying the new version did not help, the same error still occurs.

JTMaher2 commented 9 years ago

I was able to get around this issue by specifying "xterm -e" in the File->Configure terminal menu.

lethosor commented 9 years ago

@gronono, @JTMaher2, and others with this problem: what shell does /bin/sh point to on your system? I found that == does not work with with dash's test ([) command, but = does (and works with bash 3/4 as well).

Edit: zsh also doesn't like ==, but testing for an empty string with -z works in all shells I tested.

JTMaher2 commented 9 years ago

My system's /bin/sh points to dash.

gronono commented 9 years ago

Same here : dash

lethosor commented 9 years ago

Thanks, that would explain the issue. I used pyi-archive_viewer to confirm that PyLNP does embed xdg-terminal (the version that uses ==), although Pidgeot says this isn't intentional. Unfortunately, there isn't a way to replace it that I know of, but I'm looking into moving it and other files outside of the executable to make PyLNP issues easier to fix without needing to build a new executable.

baudren commented 9 years ago

Just to confirm. Zsh user here, I had the same issue than all of you, and the trick by @JTMaher2 worked for me, allowing me to run df. Looking forward for the global fix, but meanwhile, at least, it works :)

DrYitMat commented 9 years ago

The solution by @JTMaher2 did not work for me.

I tried resetting LNP to default settings. Launched and worked.

I noticed that my text was messed up. So I closed and switched print mode to TWBT. Crash. Switched it back to 2D mode, dwarf fortress launches.

So TWBT appears to be the issue, for myself at least.

baudren commented 9 years ago

Update - I also had text messed up (conversations on adventurer mode), when using the trick. I am not sure I understand the procedure you followed, @DrYitMat? Do you now have no text issues, and no crash?

DrYitMat commented 9 years ago

@baudren sorry I wasn't very clear. I have text issues, as I cannot use TWBT. Every print mode except 2D causes dwarf fortress to crash, with the unexpected operator error.

lethosor commented 9 years ago

By "crash", are you referring to the "unexpected operator" error or an actual DF crash? TwbT can cause DF to crash, but enabling/disabling it or changing the print mode in other ways shouldn't affect the launch scripts this pack uses at all, which is where the "unexpected operator" error is occurring.

DrYitMat commented 9 years ago

@lethosor I am referring to the 'unexpected operator' error. I do not receive the error when print mode is set to 2D. I receive the error when print mode is set to, Standard, TWBT, TWBT-LEGACY.

DrYitMat commented 9 years ago

Kill me. After hours of exhaustive searching I stumbled upon this:

http://www.bay12forums.com/smf/index.php?topic=140966.280;wap2

In my case the solution was to delete libstdc++.so.6 and libgcc_s.so.1 from the df_linux/libs folder.

That was way too many hours spent trying to find a solution just for it to be a simple fix. :(

EDIT: On the bright side, LNP with TWBT enabled works :D

tariqk commented 8 years ago

I've got my copy of it working with the help of @JTMaher2's workaround, so that's great.

Thing is, I'm working on getting LNP deployed into a Docker container, and I was wondering if there was a setting that I could modify from the command line, rather than trying to open PyLNP and putting in xterm -e into the “File → Configure Terminal” menu item.

I mean, worst-case scenario I'll just upload the image to Docker Hub and provide build instructions in the readme, but I was hoping to try and make it as seamless as possible.

tariqk commented 8 years ago

Found it! I managed to dig into the docker container, and in the LNP directory is a new file that doesn't exist in the initial installation of LNP, called PyLNP.user. It's a JSON file, and the settings are as follows:

{
  "terminal": "xterm -e", 
  "tkgui_height": 643, 
  "tkgui_width": 386, 
  "autoClose": true
}

So I'm all I need is "terminal": "xterm -e", and that should be enough as a workaround until a new version of PyLNP is comes up.

sparr commented 8 years ago

setting my terminal to "xterm -e" does not resolve this problem for me. after making that change, the error in the console for pylnp goes away, but now I just get an xterm popping up then closing. I can barely make out an error related to readline and a missing parameter before it closes.

lethosor commented 8 years ago

Try "xterm -hold -e"

ivanguy commented 8 years ago

got same error, but i managed to start it like so: run xterm sudo ./startlnp

axxic3 commented 8 years ago

Still not working for me in Mint 32: ./startlnp /tmp/_MEIU96pkH/xdg-terminal: 364: [: x/home/axxic3/Desktop/04023r2-i686/df_linux/dfhack: unexpected operator /tmp/_MEIU96pkH/xdg-terminal: 367: [: x-x: unexpected operator nohup: redirecting stderr to stdout

Any thoughts?

lethosor commented 8 years ago

@axxic3 did you try the solution at https://github.com/Lazy-Newb-Pack/Lazy-Newb-Pack-Linux/issues/7#issuecomment-149219775?

axxic3 commented 8 years ago

Found that file in the root 04024r3-i686 folder. It contains: { "tkgui_height": 643, "tkgui_width": 386 } But I don't understand the second statement by tariqk "So I'm all I need is "terminal": "xterm -e", and that should be enough as a workaround until a new version of PyLNP is comes up."

lethosor commented 8 years ago

Try

{
"tkgui_height": 643, 
"tkgui_width": 386,
"terminal": "xterm -e"
}

or, if that doesn't work:

{
"tkgui_height": 643, 
"tkgui_width": 386,
"terminal": "xterm -hold -e"
}
lethosor commented 8 years ago

Also, this is a fairly old pack. You may have better luck with the pack in this thread, which is a pretty recent version of DF.

axxic3 commented 8 years ago

I used the pack in the link you provided and the game launched successfully! But now when I try to use lazy newb pack ingame its frozen, so I cant use the utilities.