tests/**/*.coffee not matching root files on debian - path

I have a project which for its tests runs:
./node_modules/.bin/mocha tests/**/*.coffee -r coffee-script/register -c
tests/ looks like this:
_helper.coffee
database-tests.coffee
routers/
index-router-tests.coffee
team-router-tests.coffee
On my windows dev machine it works fine running _helper.coffee first and then the rest of the files.
On my CI server running debian it only tries to run routers/* missing out anything in the root folder.
I am assuming that tests/**/*.coffee isnt right for unix?

Moving Comments to an Answer for others since it appears to have fixed your problem.
I have had the same problems on Windows where it is not returning the files in the same order that you see them listed on the drive. I have therefore used tests/*.coffee and then tests/**/*.coffee.
I found that Windows will retrieve the files in the order they were likely written to the hard drive, while a directory or other list will have them sorted for display. This seemed to be the problem I was encountering.
The parent directory ('tests') does not seem to be included when using tests/** which seams to mean directories under the tests folder, and does not include the tests folder itself.

Related

Docker containers complain about missing files which exist in their filesystem

I recently moved my code repo from a One drive folder to my C: drive, trying to escape sync issues wiping files (thats another issue). Before doing so both my dev and prod compose files worked as expected (under source control).
Moving the files across (cloning from the repo and checking out to the branch) I ran my dev compose file which worked again as expected however my prod started complaining about "no such file or directory", "not found". I decided to snapshot the filesystem and check and could see the files and could cat the contents. So why is docker complaining?
My compose file does not use any hardcoded file paths, all relative and its evident the files are being copied across.
Compose errors:
exec docker/deployment/folder/scripts/run.sh: no such file or directory
Snapshot:
/app$ cat docker/deployment/folder/scripts/run.sh
#!/bin/sh
As previously mentioned this worked running from a diffirent local dir location. I can't imaging how that would make any diffirence.
Thanks in advance for any support.
Found the issue, vs code had updated the end-of-line sequence to crlf instead of lf.

PyCharm: Unit testing directory setup with remote interpreter

For years I've been running a Docker container on my local machine and using it as a remote Python interpreter via SSH in PyCharm. This works great (though 2022.2.1 brought a lot of new bugs that have been slowly being ironed out) for running my code! I'm now on 2022.2.3.
However, I'm having issues running unit tests. In the past (i.e. before version 2022.2.1), I could simply right click my tests directory (a direct child of my main project directory) and click Run Python tests in test... and it would all work as expected.
Now, though, when I click this, I receive an error message about "No such file or directory."
I've tried everything I can think of- I've setup my path mappings in the Python test run config to exactly match those shown in my Python run config, and have tried every version of directory and subdirectory in the mappings and working directory, but I always receive an error about either having an empty test suite (no tests found), or that the directory "must be in the project."
It seems like no matter what I do, PyCharm is trying to create a temp directory somewhere, or is trying to read from some temp directory that I never specified, because I see errors this like:
AssertionError: /tmp/pycharm_project_405/docker/tests: No such file or directory
Yet I never created, specified, or requested a temp directory of any sort, let alone one named /tmp/pycharm_project_405/; this is a mystery to me.
PyCharm with an SSH interpreter is rapidly becoming unusable for me and my team because we cannot figure out how to set this up. Can anybody please offer some guidance on what we need to do?
Thank you all so very much!
I tried:
Changing run config for Python tests to match the working directory and path mapping of Python run configs (which work)
Directly specifying the path to the tests from the container's perspective
Setting up run config templates
Specifying one directory up/down from the actual tests
Expected:
Unit tests to be found and run as they were in previous versions of PyCharm
Answer
Create a run config for testing
In the testing run config, set Target: to Custom
Set the correct remote interpreter
Set Working directory to the test folder
Set TWO path mappings: 1) Map the code directory (in my case, the parent directory of the tests folder) and 2) Map the test directory itself
Voila!!!

How to get rid of files which end in .Identifier in Laravel

I cloned a laravel-8 sail project via gitlab but everywhere in every folder which containing files there is a file which ends in .Identifier
I don't know where they come from. There may be 1000 files like this in the project.
My question is:
How can I get rid of those files which endr with .Identifier?
Is there some kind of Ubuntu or docker command that searches the entire project for such file which ends in .Identifier and then deletes them?
Maybe phpStorm has such a function?
If you are on Linux machine, then open terminal in you project folder and run rm *.Identifier. And if you are on Windows machine then open command prompt in your project folder and run del *.Identifier. This will do the trick for you.

Bazel- how to get a short but hermetic temp dir for tests?

I have a test which tries to start an embedded mysql.
It tries to write a socket file to Files.createTempFile(null, ".sock") which returns with the following error:
mysql start failed with error: [ERROR] The socket file path is too long (> 103): /private/var/tmp/_bazel_user/1c8ed8d84f6cb79483aa3cc4da758c86/bazel-sandbox/2478112867584790357/execroot/some_workspace/_tmp/dfebe48cda4dfdc8739653efedfa4933/394798020705754292.sock.
I worked around it by re-pointing java temp dir to /tmp using jvm_flags but this doesn't work when I try to use sandboxing since I guess the test isn't allowed to write there.
I've tried setting a symbolic link from the java code (like so Files.createSymbolicLink(Paths.get("/tmp/foo"),Paths.get(System.getProperty("java.io.tmpdir"))) but this doesn't seem to help.
I've also tried setting the output_base but that didn't help either.
Would really appreciate pointers and tips since I currently can't run my tests under sandbox and so can't parallelize them.
I think your approach of re-pointing Java to /tmp should work. The macOS sandbox always allows writing to a number of directories and /tmp and /private/tmp are included in this set. I tried to reproduce the failure with a genrule: genrule(name = "write_to_tmp", outs = ["out.txt"], cmd = "touch /tmp/something.sock && touch $#"), which works fine and creates the file /tmp/something.sock.
I think in general using /tmp should work fine, although it does seem to be a bit unusual on macOS. $TMPDIR is set to a user-specific folder with a randomized name underneath /var/folders by the OS and it seems to be generally encouraged to use that instead of /tmp. But if you know what you're doing, I don't see a real problem.
Note that we don't have tmpfs or similar mechanisms available on macOS, so we can't automatically guarantee that your usage of writable folders like /tmp by actions is hermetic, won't leak state between runs or that file names won't conflict. Make sure to generate file names in a secure way via mkstemp or similar.
In a bazel test, you can use the TEST_TMPDIR environment variable for a test-private writeable area.
See https://docs.bazel.build/versions/master/test-encyclopedia.html

dxgettext and Windows 10

Has anyone got dxgettext running under Windows 10?
I installed dxgettext from the offical homepage under Windows 10, which worked fine.
But whenever I try to run some of the installed tools (e.g. msgfmt.exe), they don't really run, but call themselves again, generating thousands of processes and making the system crawl.
This is what happens:
I call msgfmt --help
the executable msgfmt hangs, blocking the command window
in the TaskManager I see houndreds of msgfmt.exe processes popping up
I think, I have to replace the gettext tools of the dxgettext package with some newer version but before trying to figure it out I first wanted to ask if someone else experienced similar problems and found a working solution.
My questions:
Has anyone got the tools coming with dxgettext running under Windows 10?
What steps have been necessary to get it to run?
I resolved the problem in the following way:
I downloaded https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.19.8.1-v1.14/gettext0.19.8.1-iconv1.14-static-32.zip from https://mlocati.github.io/articles/gettext-iconv-windows.html
I replaced the following files from the installation directory of dxgettext with files from the zip archive:
msgattrib.exe
msgcat.exe
msgcmp.exe
msgcomm.exe
msgconv.exe
msgen.exe
msgexec.exe
msgfilter.exe
msgfmt.exe
msggrep.exe
msginit.exe
msgmerge.exe
msgunfmt.exe
msguniq.exe
xgettext.exe
Result:
Dxgettext and the tools, I use, seem to work fine. I found no problems with my workflow so far, with one exception:
If I use assemble to embed mo-files into an exe compiled with JvGnugettext.pas, I get the following error:
Pach code “6637DB2E-62E1-4A60-AC19-C23867046A89” was not found in .exe file. Are you sure the .exe file has been compiled with the correct libraries?
This may not be related to the original problem. However, it is resolved by replacing the original assemble.exe with the version from https://sourceforge.net/p/dzlib/code/HEAD/tree/buildtools/trunk/ (see answer by #dummzeuch).
The installer on the official home page is pretty old. Last time I looked it contained several outdated dlls and executables from the original gnugettext project that did not work correctly under recent Windows versions. You could take those from my buildtools repository on OSDN. These work for me. No guarantee that they work for you though.
https://osdn.net/projects/dzlib-tools/scm/svn/tree/head/buildtools/trunk/
I've been having these issues too with dxgettext 1.22, in Windows 10 1607. I changed some DLLs at first but kept having the bash.exe looping and hogging my PC to death.
So what I did was basically install latest Cygwin 32bit and replaced the appropiate DLLs. I kept the ones for gettext. Instructions:
Download and fresh install dxgettext-1.2.2.exe from http://dxgettext.po.dk/download as admin. Restart.
Download Cygwin 32bit from https://cygwin.com/install.html in a different folder from dxgettext (I took the default, c:\cygwin)
Run setup-x86.exe and select "Base" Package (Install). Next, Select Required packages just in case.
Move the following files from dxgettext folder to a backup folder (we'll use some DLL later):
cyg*.dll
bash.exe
Copy from c:\cygwin to the dxgettext folder the following files:
bash.exe (set to run as admin)
cygwin1.dll
cygiconv-2.dll
cygintl-8.dll
cygreadline7.dll
cyggcc_s-1.dll
cygncursesw-10.dll
Recover the file(s) below from the backup folder (See #4) and copy to the dxgettext folder.
cyggettextsrc-0-14-1.dll
cyggettextlib-0-14-1.dll
cygintl-3.dll
Running like this, you might get error 740 (requires elevation). So: Set ggmerge.exe,ggfmt.exe to run as admin
** EDIT** Found online this very interesting link, from a programmer who offers a free backup written in Delphi. The good thing is he adapted the dxgettext tools to run in Windows 10. This helped me a lot.
http://personal-backup.rathlev-home.de/translate.html

Resources