13

Bug introduced in 10.0.0 and fixed in 10.1

UPDATE: Now both the inputs "\б" and "\\б" are interpreted as "\\б" and displayed in OutputForm as "\б", InputForm["\б"] returns "\\б" and StringLength["\\б"] returns 2.

Consider:

"\бвгд" // FullForm
"\\бвгд" // FullForm

In v.8.0.4 I get this:

"\\:0431\:0432\:0433\:0434"
"\\\:0431\:0432\:0433\:0434"

But v.10.0.0 adds redundant backslash before the first backslashed Cyrillic symbol:

"\\\:0431\:0432\:0433\:0434"
"\\\\:0431\:0432\:0433\:0434"

screenshot

As the result it is not possible to open any file which name (or name of a directory in the path) starts from a Cyrillic symbol.

Also after evaluating the above (in the case the Cyrillic symbols were typed, not pasted in the Notebook) the following bugs appear:

  • When I try to cut by pressing Ctrl+X any Cell or group of cells in this Notebook I get http://demonstrations.wolfram.com/ opened in my browser and nothing changed in the FrontEnd

  • After some additional editing (entering backslashed Cyrillic symbols after the quote " but without entering the closing quote and without evaluation of the cell) an attempt to cut an input cell by pressing Ctrl+X results in commenting all the code in the selected input cell. Pressing Ctrl+X again uncomments the code.

All the above manipulations with Ctrl+X give this result when English keyboard locale is selected.

Does anyone also observe this? Is there a workaround?

P.S. OS Win7 x64.

Michael E2
  • 235,386
  • 17
  • 334
  • 747
Alexey Popkov
  • 61,809
  • 7
  • 149
  • 368
  • I think this may have to do with the change to a single system font. In previous versions, '\бor other Cyrillic character would not replace \ with \\, whereas this would happen with Latin characters (as long as they weren't escape sequences). This was true in v9 as well, but in v10 letters from both alphabets behave the same. Does the single slash not work for you? On Win 8.1 x64 (v10) this works fine for me:Import["алексей\попков","Text"]>привет!` – mfvonh Jul 14 '14 at 14:57
  • One workaround for Import is to use FileNameJoin. – Alexey Popkov Jul 14 '14 at 15:30
  • 2
    I'm not an expert but I don't think "\\:0431\:0432\:0433\:0434" is properly formed -- that is, I think the bug is in V8.0.4 (and V9.0.1, too). If I paste the string in V8.0.4 and execute it, the output displays as nine characters, \:0431вгд, which seems the proper interpretation (compare with StringLength["\бвгд"]). A similar thing happens with other unicode characters. That it used to work suggests offsetting bugs or intentional flexibility in processing resource-locator strings. Similarly, the V10 string "\\\\:0431\:0432\:0433\:0434" seems to be missing a backslash. – Michael E2 Jul 14 '14 at 16:09
  • @Michael It sounds like we have bugs both in versions 8,9 and in v.10 but now the things become worse: filename handling is broken. – Alexey Popkov Jul 14 '14 at 17:51
  • I usually use FileNameJoin anyway, or do you mean it's not working? (Btw, I don't have Windows, so I can only check the filename string in Mma; I can't check whether the file can be opened with the string.) – Michael E2 Jul 14 '14 at 18:00
  • @Michael It works, check my answer. – Alexey Popkov Jul 14 '14 at 18:16
  • Possibly related – Szabolcs Jul 21 '14 at 02:24
  • I have the same problem with broken shortcuts. – Vladimir Reshetnikov Sep 04 '14 at 18:17
  • In 10.0.1 I get three slashes in both cases. – Sjoerd C. de Vries Sep 17 '14 at 14:43
  • Has this been fixed now? We should mark it appropriately if possible. – Mr.Wizard May 16 '15 at 07:07
  • @Mr.Wizard Yes, in version 10.1.0 the described bugs are fixed. I'm not sure in which version they were finally fixed. – Alexey Popkov May 16 '15 at 13:24

1 Answers1

12

For file operations two workarounds currently work:

1) Use slash / instead of double backslash in the paths to files under Windows:

Import["D:/test/кириллическое название/файл.txt"]

2) Use FileNameJoin or StringJoin:

Import[FileNameJoin[{"D:", "test", "кириллическое название", "файл.txt"}]]

Import[StringJoin[{"D:", "\\", "test", "\\", "кириллическое название", "\\", "файл.txt"}]]

Note that both produce just ordinary double-backslashed output:

FileNameJoin[{"D:", "test", "кириллическое название", "файл.txt"}]

"D:\\test\\кириллическое название\\файл.txt"

Manipulations inside of the Kernel are safe:

path = File /. FileInformation["D:/test/кириллическое название/файл.txt"]
Import[path]

"D:\test\кириллическое название\файл.txt"

(Import works as expected).

But copying this and pasting into the FrontEnd gives a string that is parsed incorrectly:

Import["D:\\test\\кириллическое название\\файл.txt"]

During evaluation of In[12]:= Import::nffil: File not found during Import. >>

$Failed

So it is clear that this is a FrontEnd bug.

Alexey Popkov
  • 61,809
  • 7
  • 149
  • 368