Ticket #2841 (closed defect: invalid)
maxima pukes on non-ascii filenames (terrible evil bug! - caused by clisp?)
| Reported by: | was | Owned by: | mabshoff |
|---|---|---|---|
| Priority: | minor | Milestone: | sage-duplicate/invalid/wontfix |
| Component: | packages: standard | Keywords: | |
| Cc: | Work issues: | ||
| Report Upstream: | N/A | Reviewers: | |
| Authors: | Merged in: | ||
| Dependencies: | Stopgaps: |
Description
> Do you have any files anywhere in your filesystem that might not > just use standard ascii characters in their names? > I'm guessing a bug in Maxima is causing the problem. Maxima tries > to read various directories on startup and behaves very stupidly in > the presence of filenames that contain characters that confuse it. > Could you try making a new clean user account and running > sage -maxima > from it? Thank you!! On a new user account sage and its maxima worked beautifully. On my main account I found a folder called "Steuerfälle" generated by a governement-software for calculating the taxes in Switzerland... I changed that -> issue gone. Thank you very much, William. I'm looking forward to having a great time with sage.
Change History
comment:2 Changed 5 years ago by mabshoff
- Summary changed from maxima pukes on non-ascii filenames (terrible evil bug!) to maxima pukes on non-ascii filenames (terrible evil bug! - caused by clisp?)
Well, this is actually likely to be a clisp issue, so hopefully once we switch to ecls this issue will be gone regardless if this is actually an env issue or not.
Cheers,
Michael
comment:3 Changed 3 years ago by kcrisman
- Priority changed from major to minor
- Report Upstream set to N/A
Is this still an issue, given the comment above and #276, and the recent fix of ECL to not scan the filesystem (did that ever cause this problem? Changing to minor with no complaints like this in two years.
comment:4 Changed 3 years ago by kcrisman
Suggesting that we might make a change to sage-env if this isn't a problem anymore.
# If the language encoding isn't set, set it to be US, since
# Sage is currently mainly a US program, and leaving this off
# leads to some really confusing errors -- see trac #276
if [ "$LANG" = "" ]; then
LANG="en_US.UTF-8" && export LANG
fi
But Sage isn't anywhere near as much mainly a US program now, and hopefully this problem isn't possible anymore? I did create a folder called "Steuerfälle" on my computer and that didn't cause problems, and LANG=en_US.UTF-8 still (even when I open a new terminal window).
So perhaps we should revert #276 - or at least close this ticket!
comment:5 follow-up: ↓ 6 Changed 3 years ago by mpatel
It appears that #2513 (changeset 1231:7ae8bf22920b in the scripts repository) has already reverted #276.
Should we wait for reports about non-ASCII file/folder names?
comment:6 in reply to: ↑ 5 Changed 3 years ago by kcrisman
Replying to mpatel:
It appears that #2513 (changeset 1231:7ae8bf22920b in the scripts repository) has already reverted #276.
Hilarious! Just goes to show that Sage is too big for any one person to know all about it - or at least to remember all tickets.
Should we wait for reports about non-ASCII file/folder names?
No - this should be pointed out as fixed elsewhere and the ticket closed, imho.
If you agree, then I would say just put a note to that effect on that thread.
Note that this was previously reported (and fixed, at least for me) as #276.
Perhaps the bug reporter has LANG set to an encoding that does not handle that particular file name; or perhaps LANG is not set, and en_US.UTF-8 does not work on that machine (or at least, that file name is not a valid UTF-8 string).