I can't figure out how to get apostrophes displaying correctly in my Perl documentation. For example, the text 'test' displays as âtestâ.
E<39> also renders as â
also I<'>
also S<'>
also E<apos>
C<'> renders as "'" (so apparently the terminal isn't the problem)
F<'> renders as underlined â
I've also tried running perldoc with -T, -n nroff and -n troff but none made a difference. Running with -t fixed the apostrophe problem but also kills all other text attributes.
I've been putting up with this for a while, but it's really starting to irritate me. How can I get them displayed correctly?
#hwnd's bug report led me to the LANG environment variable. By changing it from en_US.UTF-8 to en_US I can get the perldocs displaying correctly. Not sure if this will cause problems elsewhere but so far I haven't run into any.
Upgrade Pod::Perldoc and use the -o term backend.
can't say i know lots about this issue, but this has worked for me in the past when characters don't appear correctly:
binmode(STDOUT, "utf-8");
Related
I'm using something like this in a script:
REPLY=$(rlwrap head -n 1)
Actually with more options but that suffices to reproduce the issue. It works perfectly for my purposes... as long as I don't press Ctrl-C to quit. If I do, input echo stops on the terminal and the only way I've found to restore it is to blindly type reset.
The -I flag didn't help. I also tried this:
rlwrap head -n 1 | REPLY=$(cat)
but then REPLY wasn't set when I pressed Enter. I've tried in both bash and dash, with identical results EDIT: Sorry, due to a typo on the shebang, dash was not being executed. It works correctly in dash.
How can I set a variable to the output of rlwrap and be able to interrupt without losing input echo? Also out of curiosity, does anyone know what's going on here?
Your use of rlwrap within a $(...) construct is correct. That you can do this is part of rlwrap's "transparency": whatever works with <command> should also work with rlwrap <command>.
I cannot reproduce the problem on any of my systems.
This means you found a bug. You already posted an issue on the rlwrap Github site.
Edit: straceing rlwrap on two systems, of which only one displays the bug, doesn't show any significant differences, so we conclude that this is probably not a rlwrap problem.
I was wrong about dash. It actually works fine under dash, therefore my solution was to stop using bash-specific features in the script and switch it to dash.
Update: Later I found that using this as the shebang makes it work with bash too:
#!/bin/bash --noediting
which basically disables readline for bash.
I am using Per Tidy plugin in Padre IDE. By default, Tidy wrap my long lines into multiple lines which I don't like. How can I tell Tidy never wrap my lines?
Testing via perltidy on the command-line (referring to the man page), I found that I preferred to change the default perltidy options to always keep newlines (line breaks) by enabling "freeze newlines" (-fnl), and and disabling all whitespace modifications (-fws, freeze whitespace), via options: perltidy -fws -fhl -b
For your specific case, to ignore all line breaks, all you would needs is perltidy -fnl -b (the -b creates a backup file, and modifies in-place.)
There's also a second reasonable option of just setting the line length much longer (for example to 120 chars) than the default of 80 using: -l=120 (or: --maximum-line-length=120 or an even longer "really large number" is enabled by setting it to zero (0).
Note: as an aside, I'm testing on bluefish html editor, which uses either html tidy or perltidy, depending. For some reason, I had to change the rc file directly and couldn't change the setting in the GUI.
You can also change the default settings of perltidy. First find out where it is installed:
perl -MPerl::Tidy -e 'print $INC{"Perl/Tidy.pm"}'
Then edit the file where maximum-line-length is defined (or any other parameters you want). You might need sudo if perltidy is installed gobally. I usually use VS code to format my code and that in turn uses perltidy but I can't define paramters. So I found doing this particularly useful.
I have an infected website, and I am trying to clean it out using sed. Unfortunately I am unable to escape the question mark sign in the URL and I am really stuck here. I've searched over the web for a possible solution, but unfortunately I didn't found a proper way to do so.
Just an explanation:
The injected code is similar to this one:
< iframe src=http://test.com/index.html?i=23123>< /iframe>
Note that I am not a pro, and there is why I need your help!
so my way to clear the code is :
sed -i '/< iframe src=http:\/\/test.com\/index.html\?i=23123>/,/< \/iframe>/d' index.html
Unfortunately that didn't help as well as all others.
All help will be gratefully appreciated.
echo "< iframe src=http://test.com/index.html?i=23123>< /iframe>" \
| sed 's#< iframe src=http://test.com/index.html?i=23123>< /iframe>##'
Produces no output, which to me means this is successfully deleting your problem string.
Note that most seds will accept an alternate regex-replacement character, here I am using # because there are no #s in the search target. On some seds, you have to tell it 'hey I'm using an alternate, and escape the char, like s\#.....##.
I don't see why your attempt to quote the ? is failing. Did you try [?] and (worst case) [\?]. Are there 2nd level evaluations happening by the shell that you're not mentioning here? Does my simple example also fail?
As others will certainly tell you, your approach is strictly a bandaid, you need to figure out what the security hole is in your system and fix it. Your pages will get corrupted again. :-(
IHTH
Here is what I have:
use Term::ANSIColor;
print "Blah!".color("green");
The output is
Test←[32m
What am I missing?
The terminal program you are using does not support the ECMA-48 color escape codes. So it does not give them any special treatment, and instead outputs the characters as-is.
What you are missing: a terminal that does. xterm, libvte, putty, are just a few to name that do.
Are you on Windows? I'm fairly certain that the Windows shell isn't compliant with the color codes used by the module.
Actually, it says so right there on the module's documentation.
Note that not all displays are ISO 6429-compliant, or even X3.64-compliant (or are even attempting to be so). This module will not work as expected on displays that do not honor these escape sequences, such as cmd.exe, 4nt.exe, and command.com under either Windows NT or Windows 2000. They may just be ignored, or they may display as an ESC character followed by some apparent garbage.
EDIT:
An addendum to my comment:
C:\>perl -MWin32::Console::ANSI -MTerm::ANSIColor -e "print color(\"green\"), 'test', color(\"reset\");"
Works just fine on Windows XP, Perl 5.12.1, so there's your workaround.
I'm using grep from the command line via cygwin. I'm wondering if there's any way to get it to highlight the part of each line that matches the regex. The closest thing I'm seeing is the -o option, but that only outputs the matching area, and I'd like to see the entire line.
Take a look at the --color (or --colour) option, e.g.
grep --color POST access_log
By default, this uses the "auto" mode which only includes the color codes when output to a terminal, but not when you pipe the output elsewhere. If you want the colors piped out to something other than stdout, then use --color=always
See the linked article for ways you can change the colour and make grep use this option by default.
Try the --color switch.
You might want to try the ack tool. It does the highlighting by default, iirc.
Actually, it does many usefull things by default. Some people like it and I hope You will too.