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.
Related
Issue:
My java sprig-batch job runs fine in my development environment, but when I deploy it on the integration server, I get a date-formatting issue. This makes me think there is a configuration difference between my dev. env. and the integration server.
Context:
I am not a java or spring expert. This is rather an integration issue.
I call a MY.PROCEDURE piece of PL/SQL code, that in turn calls an Oracle view.
The below instruction in the Oracle view works fine in my dev. env., but on the integration server it is causing the issue:
T1.DATE between '01.07.2015' and '07.07.2020'
Giving an ugly
Caused by: java.sql.SQLDataException: ORA-01843: not a valid month
ORA-06512: at "MY.PROCEDURE", line 36
When I specify the date format with a TO_DATE, it vanishes. I know this is good practice, and should obviously be mandatory for our team to do. Anyway I would like to understand this configuration discrepancy we have between Dev and Int.
Help
Any idea where I should configure the locale when I deploy this thing?
I wish I could setup the local (or date format) locally, without modifying the java deliverable. Is it possible ?
It appears as though your NLS_DATE_FORMAT is different in your environments. Run the following in each environment:
select value
from nls_session_parameters
where parameter = 'NLS_DATE_FORMAT';
This is why you should always specify the format and not rely on implicit conversion. If necessary you may be able to run the following:
alter session set nls_data_format = 'mm.dd.yyyy';
or perhaps that should be 'dd.mm.yyyy'. That cannot be determined from the given information.
The environment difference between development and the integration server is the first is a Swiss(FR) setup OS. And... the server is a Linux with the default English's.
So you start to see where I have to go.
Tell Java you run your thing with 'fr' locale:
I had to complete the java command line with the below:
-Duser.country=fr -Duser.language=fr
Here is where I found inspiration: NLS_LANG setting for JDBC thin driver? (most upvoted answer).
Having used robot framework for almost a year, it suddenly stopped working. Starting a script gives only the response
'pybot' is not recognized as an internal or external command, operable program or batch file.
Running scripts worked yesterday, and I can't remember making any changes since then. I have checked the environment variables, they haven't been changed. The installation is on a Windows Server 2012. Python is still working as usual. There is no difference between using pybot or robot.
Now I just don't know what else to look for, and I'm asking you geniuses to give some ideas on where to search for this error.
One of two things happened:
robot framework was uninstalled
something in your environment changed so that pybot is no longer on your PATH
Both of those should be very easy to verify.
It turns out that the python/scripts folder had been moved by someone into the python/Lib folder. Simply putting it back solved the issue.
I have an exe file (Windows environment) which runs OK on Windows 10, but eventually it produces an error ("Can't find folder %USERPROFILE%\Local Settings\folder\\Tempfolder"). Needless to say, the folder does exist. I looked into the exe file with a hex editor and I found out that somewhere there is (hardcoded) the URL of this specific folder, in cleartext. It looked the same as the error message:
"%USERPROFILE%\Local Settings\folder\\Tempfolder".
I wonder if there is a mistake in the URL -- the double backslash before the last subfolder. As you can see from the example above, the double backslash appears only at the last subfolder, so I don't think that it is interpreted as an escape character.
So I tried deleting the extra backslash with the HEX editor, save and execute, but when I did so Windows 10 stopped being able to execute it, it said something like "This cannot be recognized as a Windows application".
Why does this hapen?
Is there a way to do this without messing up the executable?
(Note: the URL above is an example, I won't write the real one because the exe is actually a dubious tool of the cracking genre)
STOP!
DON'T USE THIS FOR WHAT THE ASKER IS DOING. IT MIGHT MESS STUFF UP EVEN MORE.
Add a 0x00 byte on the end of the string. :)
And also update the checksum.
If it's signed, you're outta luck.
If you don't wanna update the checksum, use CFF Explorer.
I cannot get phabricator to display the changes in using the file context. I got the "Context not available" on every file.
Does anyone know why is this not work? What should i do to debug this problem?
This seems a problem related with SVN only because its working with GIT.
Thanks.
I bumped in the same problem recently and googled this question. I found out that the context is available only when diff is created via arcanist command line tool (arc diff) in Linux or Mac OS.
It won't work if you create a diff directly by pasting it in Phabricator/Differential or by using arcanist tool in Windows.
I tested this with arcanist on Ubuntu 14.04, Mac OS 10.10 (those two worked) and in Windows 7 (didn't work).
You didn't specify whether you're using the arc diff command line tool, or manually uploading a diff via the Phab. web interface.
If you're not using arc diff, I have an answer for you: It's up to you to include the context yourself. Phab. only knows what's in the diff/patch that you give it. If you can't get the full context, that's a fault with your diff/patch, not with Phab.
If you're using a standard diff utility, like GNU diff, you can use the command-line arguments to dictate how much context to include in the output. I usually use some obscenely large number, like 500 or 1000, to ensure that the entire file ends up in the output.
I just took a quick look at the svn command-line documentation, and it seems that there's no way to control how much context goes into the output. ...but maybe I'm wrong...
In any case, shortboy is correct that the easiest way to get the full file context is to use arc diff.
I have a question regarding the use of M-x man in Emacs. I'm working with Tramp all the time and often the installed program base on the remote server differs significantly from my local setup. I see that invoking M-x man involves looking for the relevant manpages on the local machine. Is there a way to instruct it to use the environment on the other side of Tramp?
I know there's an Elisp variable tramp-remote-process-environment and I've tried adding an entry for MANPATH to it, but it doesn't seem to work (I'm afraid it's because I put it in the form /usr/share/man instead of /scpc:user#host:/usr/share/man but what I want is a generic solution to work on all remote hosts). Any ideas?
From the Man-start-calling macro in man.el:
(let (...
(default-directory
(if (and (file-directory-p default-directory)
(not (find-file-name-handler default-directory
'file-directory-p)))
default-directory
"/"))
That is, if there is a special file name handler for the current default directory, such as Tramp, it will use the root directory as the directory to start man from, and thus it will see man pages from the system that Emacs is running on.
There doesn't seem to be a way to disable this apart from changing man.el. Note that this is a macro, so you need to reload the macro and all the functions that use the macro.
From docstring of command man would expect it's able to read remote pages:
An explicit filename can be given too. Use -l if it might
otherwise look like a page name.
/my/file/name.1.gz
-l somefile.1
You may write a caller, which reads the environment and composes the needed argument.