Boost.asio HTTP Client issues with \r vs \n - http

I'm trying to use the HTTP client example code (sync_cleint.cpp) to retrieve a jpg. I'm using VS2008 on a Windows XP machine and trying to access a Linux server. The resulting data I get back does not start the new lines at the same place as data I retrieve by simply downloading. I believe this is an issue with how windows interprets a new line, \r\n, versus how unix/linux interprets a new line, \n. The example code (http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio/example/http/client/sync_client.cpp) uses \r\n, \n, and \r, so I'm a little confused on how to rectify the problem. Any suggestions to correct this for my case (hard code) or automatically detect would be greatly appreciated.
P.S. I'm using boost 1.48.0

Related

Plotly tooltip showing unicode character instead of letters in shiny server (R

I have a shiny application running in a shiny server that started giving errors for all accented characters today (it was working with no errors until yesterday night).
I realized that all files seemed to be sourced using other types of encoding than utf-8. Thus, I tried forcing it using source('file.R', encoding='utf-8') , but this gives an error and the application doesn't run.
Since I could not find the reason to why this was happening, I changed all characters to their unicode format (\u00xx) and used the enc2utf8 where needed.
After doing this, most of the application seemed to be working fine. The only problem that I am having now, is that the tooltip of my plotly charts started showing the unicode value instead of the character as shown in the image below. I tried not using the enc2utf8 on those dataframes but it also showed the characters with errors. For example, it should be Ăšltimo but it appears <c3><9a>ltimo when not using the enc2utf8.
How do I solve this problem? Is there a better way to force the files to be read in utf-8 instead of wharever encoding it is being read?
Extra information:
In RStudio I am saving all files as UTF-8 by default, so I assumed the encoding should not be an issue
In my local machine (windows) the application runs just fine and the plots are shown perfectly. The errors only occur on the server that runs in a linux machine

Unix OVO (hp operations manager) suppressing an alert with backslash

I'm trying to suppress an alert in a system called HP Operations manager probably more commonly known as OVO (very old system i know) however i'm struggling with the UNIX protected characters because i am trying to suppress a windows alert from the Microsoft\Windows path, so anything before it and after it in the log file can change just want to exclude everything from Microsoft\Windows.
I have tried using double backslashes \ as i have done some research and found that the first \ mitigates the meaning of the second \ therefore \ = \, this doesn't work for me, so far I've got <>"\Microsoft\Windows"<> that doesn't work, but i have also tried \Microsoft\Windows to no avail.
I don't really have a test platform so it's been just trial and error so far, however i will know when it finally works because i will no longer receive these alerts.
Long story short is i want to know how to handle windows file paths e.g xxx\xxx\xxx\ in UNIX so what do i change \Microsoft\Windows to for it to be recognized in UNIX

YAML - Escape \ in double quotes

I'm having the following issue:
Classic symfony 2 project, phpunit 5.1.7.
In one yml config file I have something like this:
mobile_detect:
service:
mobile_detector: mobile_detect.mobile_detector.default
twig_extension_class: "SunCat\MobileDetectBundle\Twig\Extension\MobileDetectExtension"
I run tests on my local machine (ubuntu) and everything works fine.
Then I deploy code (aws environment) and try to run tests. Everything fails with error:
"Unescaped character \M".
I see that in yaml double quotes parse strings so \M is indeed an undefined character. My question is... Why is it working file on local?
Also, the code works fine when I try to access normaly (through apache - browser call). Why is that also working well?
I guess the correct approach would be to replace all double quotes with single quotes but that would be really time consuming (can't do replace all beacause in some cases using them like that may have been intended). Is there any way to make tests on the tests machine to interpret yml as they do on the local machines?
Is there any way to make tests on the tests machine to interpret yml as they do on the local machines?
You are asking whether you can reproduce the incorrect behavior of the code on your local machine somewhere else. Depending on incorrect behavior is one of the worst things you can do; it tends to get fixed by software updates.
As you state yourself: The correct way is to fix you invalid YAML files. Be it by using single quotes or by escaping the backslashes with another backslash. There is no solution for keeping the current YAML files that is guaranteed to work when you update your software stack.

Convert API failing in certain situations

We have a site that uses ConvertAPI to create PDFs and download them. They are working in most instances but are failing with large files in certain circumstances. Here's what I could gather:
1: it only happens with a large PDF.
2: it only happens on the mac
3: it appears to have a commonality with Acrobat where Acrobat's plugin called "Web2PDF" is listed as "loaded: no" on the two machines that are not correctly allowing the ConvertAPI code to work. There's another mac where it DOES work in our office, but that mac is working fine.
Anyone seen this before? Help?
Thanks.
Paul
It is hard to say for sure what is the problem, as there is no information about which command is used. However, the similar problem occurs with large files if you are using the ConvertApi with a secure https URL instead of the http, as in this case:
Powerpoint upload stops at ~9MB with cURL -F
Please let us know if changing to the http URL helps with the problem.

QFileInfo::exists() for a shared-drive file path

Question from a newcomer to QT: when I supply the exists() method of a QFileInfo object with a shared-drive file path, it always returns false, even with me escaping every backslash with another backslash (i.e. \\10.1.2.34.56\dir1). And yes, the directory does exist :) Could there be some other issue at work here, such as a lack of permission for the directory in question? Thanks in advance for any light you might shed on this issue...
It seems it works correctly on XP (with Qt 4.7.3) either with doubled backslashes or single slashes ('//ip/share/filepath').
Try getting the file url through QFileDialog::getOpenFileName. As it uses a native dialog, it should ask for your login/password if needed.
If QFileInfo can then find that the file exists, you could try using the native API (Windows Networking) to connect or allow access programmatically to the network share.
As it turns out, my issue had everything to do with permissions and nothing to do with escaping backslashes.
The application I inherited actually has two components: i) the window that provides the GUI interface for the app and (ii) the Window service that does the actual work. The window was able to "see" the shared drive because the Windows userid for which it was running had permission for that drive, whereas the Windows service running as the local system could not. Once I used the Services window to change the service to run under a userid with permission for that drive, then it ran just fine. Thanks for your response...

Resources