Open gronono opened 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.
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
I seem to get something similar:
Traceback (most recent call last):
File "/usr/bin/gnome-terminal", line 3, in
I looked into this problem, and it appears to be a problem with pyLNP.
I'm looking into a fix now.
Wasn't this fixed in #8 / b0038304e6c1cfc63fa8e30d16a5a7e8eadd7672?
@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
.
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?
@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
Getting hit by this issue as well.
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.
I was able to get around this issue by specifying "xterm -e" in the File->Configure terminal menu.
@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.
My system's /bin/sh points to dash.
Same here : dash
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.
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 :)
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.
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?
@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.
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.
@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.
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
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.
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.
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.
Try "xterm -hold -e"
got same error, but i managed to start it like so: run xterm sudo ./startlnp
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?
@axxic3 did you try the solution at https://github.com/Lazy-Newb-Pack/Lazy-Newb-Pack-Linux/issues/7#issuecomment-149219775?
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."
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"
}
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.
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.
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 ?