Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot use qqx in rakudo star on windows7 #5318

Open
p6rt opened this issue May 16, 2016 · 10 comments
Open

Cannot use qqx in rakudo star on windows7 #5318

p6rt opened this issue May 16, 2016 · 10 comments
Labels

Comments

@p6rt
Copy link

p6rt commented May 16, 2016

Migrated from rt.perl.org#128154 (status was 'open')

Searchable as RT128154$

@p6rt
Copy link
Author

p6rt commented May 16, 2016

From @teodozjan

$ perl6 -v
This is Rakudo version 2016.04 built on MoarVM version 2016.04
implementing Perl 6.c.

$ perl6
To exit type 'exit' or '^D'

qqx{dir}
Unable to read from 'dir'
  in block <unit> at <unknown file> line 1

@p6rt
Copy link
Author

p6rt commented Jun 15, 2016

From @zoffixznet

Can you switch to a different directory (e.g. C​:\) before trying to run the command and see if it still fails?

Also, can you try running it outside of the REPL, just with perl6 -e 'say qqx{dir}'

I can't reproduce with R* 2016.04 on Windows 10 x64.

@p6rt
Copy link
Author

p6rt commented Jun 15, 2016

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jun 15, 2016

From @teodozjan

On Tue Jun 14 19​:39​:47 2016, cpan@​zoffix.com wrote​:

Can you switch to a different directory (e.g. C​:\) before trying to
run the command and see if it still fails?

Also, can you try running it outside of the REPL, just with perl6 -e
'say qqx{dir}'

I can't reproduce with R* 2016.04 on Windows 10 x64.

Hi Zoffix,

Things you asked for. Hope it helps.

$ cd \
$ perl6 -e 'say qqx{dir}'
===SORRY!=== Error while compiling -e
Unable to parse expression in single quotes; couldn't find final "'"
at -e​:1
------> 'say<HERE><EOL>
  expecting any of​:
  single quotes
  term

$ type test.p6
use v6;

say qqx{dir};

$ perl6 test.p6
Unable to read from 'dir'
  in block <unit> at test.p6 line 3

Actually thrown at​:
  in block <unit> at test.p6 line 3

@p6rt
Copy link
Author

p6rt commented Jun 15, 2016

From @teodozjan

On Tue Jun 14 19​:39​:47 2016, cpan@​zoffix.com wrote​:

Can you switch to a different directory (e.g. C​:\) before trying to
run the command and see if it still fails?

Also, can you try running it outside of the REPL, just with perl6 -e
'say qqx{dir}'

I can't reproduce with R* 2016.04 on Windows 10 x64.

Another interesting result
$ perl6 -e "say qqx/dir.exe/"
File Not Found
Volume in drive C has no label.
Volume Serial Number is 04FC-3A2A

Directory of c​:\Windows\SysWOW64

@p6rt
Copy link
Author

p6rt commented Jul 27, 2016

From @teodozjan

Also tested on 07 rakudo star with fresh windows 7 with same result

@p6rt
Copy link
Author

p6rt commented Jul 11, 2018

From @teodozjan

I found resolution. It looks like it is problem windows locale issue than perl itself.

Running command

  chcp utf8

Makes work just fine. Default is 852. I'm very supprised because I use unicode encoding all the the time and never had such issue. For me it would be better to detect if codepage is set to 852 and warn user that perl6 may not work well. Shall we close it or leave defect for future improvement?

@p6rt
Copy link
Author

p6rt commented Jul 11, 2018

From @stmuk

Maybe the Windows port of rakudo should set this automatically on startup?
On Wed, 11 Jul 2018 at 10​:08, Kamil KuÅ�aga via RT
<perl6-bugs-followup@​perl.org> wrote​:

I found resolution. It looks like it is problem windows locale issue than perl itself.

Running command

chcp utf8

Makes work just fine. Default is 852. I'm very supprised because I use unicode encoding all the the time and never had such issue. For me it would be better to detect if codepage is set to 852 and warn user that perl6 may not work well. Shall we close it or leave defect for future improvement?

--
Steve Mynott <steve.mynott@​gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

@p6rt
Copy link
Author

p6rt commented Jul 12, 2018

From @teodozjan

Will it work fine for utf-16 users?
On Wed, Jul 11, 2018 at 11​:16 AM Steve Mynott via RT
<perl6-bugs-followup@​perl.org> wrote​:

Maybe the Windows port of rakudo should set this automatically on startup?
On Wed, 11 Jul 2018 at 10​:08, Kamil KuÅ�aga via RT
<perl6-bugs-followup@​perl.org> wrote​:

I found resolution. It looks like it is problem windows locale issue than perl itself.

Running command

chcp utf8

Makes work just fine. Default is 852. I'm very supprised because I use unicode encoding all the the time and never had such issue. For me it would be better to detect if codepage is set to 852 and warn user that perl6 may not work well. Shall we close it or leave defect for future improvement?

--
Steve Mynott <steve.mynott@​gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

--
Pozdrawiam

Kamil Ku�aga

@p6rt
Copy link
Author

p6rt commented Jul 12, 2018

From @stmuk

I'm not sure. Probably your idea of warning about detected encoding is better.

S
On Thu, 12 Jul 2018 at 09​:58, Kamil KuÅ�aga via RT
<perl6-bugs-followup@​perl.org> wrote​:

Will it work fine for utf-16 users?
On Wed, Jul 11, 2018 at 11​:16 AM Steve Mynott via RT
<perl6-bugs-followup@​perl.org> wrote​:

Maybe the Windows port of rakudo should set this automatically on startup?
On Wed, 11 Jul 2018 at 10​:08, Kamil KuÅ�aga via RT
<perl6-bugs-followup@​perl.org> wrote​:

I found resolution. It looks like it is problem windows locale issue than perl itself.

Running command

chcp utf8

Makes work just fine. Default is 852. I'm very supprised because I use unicode encoding all the the time and never had such issue. For me it would be better to detect if codepage is set to 852 and warn user that perl6 may not work well. Shall we close it or leave defect for future improvement?

--
Steve Mynott <steve.mynott@​gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

--
Pozdrawiam

Kamil Ku�aga

--
Steve Mynott <steve.mynott@​gmail.com>
cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant