I'm having a hard time using assetics to load resources in my views (I work with Symfony2).
I was working on Linux (Ubuntu 10.4) and switched to Windows 7 a few days ago. I've always been having trouble (some images didn't load for example), but at least most images, and all styles and scripts were loading alright.
When I switched to Windows, some resources weren't loading, so I tried a php app/console assets:install web --symlink
I was quite surprised to see that it had deleted the whole public folder of the bundle I was working on. And there was no way to find the sources again (fortunately, I had saved some of them, and I was able to retrieve most of my work thanks to cached files).
After I've recovered my files (and backed them up), I tried to command again. Same result. I tried without the --symlink and it created some folders in the web/bundle folder, instead of files that were there before (supposedly, the symlinks).
Now the command doesn't even answer anymore (it has been erasing my sources even in some of my backup folders!!).
Bottom-line : is there a way to configure assetics on Windows 7 so that it doesn't eat my files and loads the resources (including images in css) correctly?
Thanks in advance!
Edit :
I just ran the command again and this time it worked (copied the files in web/bundle/...). I must say I don't really understand how or why it worked this time... If by chance anyone knows...
In order to run assets:install web --symlink on a PC you need an elevated command prompt (fancy word for cmd.exe in Administrator mode).
Symfony2 uses the PHP symlink function, according to the docs it should work for Windows Vista, Server 2008 or greater.
By default only Administrators can create symlinks in Windows. So you'll have to use an elevated prompt or give your user the SeCreateSymbolicLinkPrivilege privilege.
You can do it with windows console, but Git Bash is much nicer. Get it and download. Ps. If you never used git before this is the right time to start. :)
When you installed it search in windows programs for git bash and right click it to run as administrator. If you have Git bash opened from the right click in the current folder "git bash here" it wont work because it is not launched by default in administrator mode. If you done this you get this warning.
app/console assets:install web --symlink
Warnings. Hard copy where used instead of symlinks.
However if you play nice and do it as i said. (run as administrator.. you will get everything work nice and smooth.
app/console assets:install web --symlink
Symlinks where created! :) Now you don't need to assets:install every time you made changes to your css files.
Ps. git bash console is nicer then native windows console but... for example Unix system such as Ubuntu would look even better. Also Symfony on Windows with Xamp will run much slower than on Linux Ubuntu system. I am talking about 5x to 20x faster page response on Linux.
You can use configure the composer.json and use forever without any problems,puting in it --symlink.Here is how you can do it.
http://www.w3docs.com/snippets/symfony/how-to-keep-symlinks-in-web-bundles-after-composer-update.html
You can add this configuration option in your composer.json:
{
"extra": {
"symfony-assets-install" : "symlink",
}
}
Related
I am trying to develop Laravel app using WSL 2 and Docker. I have followed official Laravel instructions for Windows development (https://laravel.com/docs/9.x/installation#getting-started-on-windows).
in WSL console I run:
curl -s https://laravel.build/example-app | bash
cd example-app
./vendor/bin/sail up
Everything seems to be fine (example-app is running on http://localhost), except I don't know how to do the actual development, i.e. edit the sources to see changes in the app.
I believe I have to somehow 'mount' directory sources from inside WSL/Docker into my Windows file system, but I don't know how.
I don't want to use VSCode (Laravel docs suggest that), I want to use IDE of my choice and access project files in general.
In the end I found out that this problem boils down to accessing WSL file system - Docker/Laravel files are synced automatically from there.
WSL file-system can be accessed through a path that looks something like this:
\\wsl$\Ubuntu\home\your-username\example-app
For some reason this was not visible in the Network section of Windows Explorer. You must type it manually or use the following trick:
Open WSL Linux console and go to the folder with your Laravel app. Then type the following:
explorer.exe .
(notice the dot)
This will open Windows Explorer at your current location and you will be able to copy the path and paste into your IDE.
I updated my cygwin using the setup-x86_64.exe tool (version 2.873) on Windows 7.
I needed to install some additional packages (mostly zip/unzip etc).
Since then, I am getting the following errors when I try to run the Cygwin Terminal (the shortcut points to C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -):
Error: could not fork child process: Resource temporarily unavailable.
DLL rebasing may be required. See 'rebaseall / rebase --help'.
I searched online how to run the rebaseall command they advise in the message. Essentially the recommendation was to start cygwin/bin/dash.exe and run:
bin/rebaseall
I did that a few times, I also used the -v comment, and no errors come back. Still I can't start cygwin.
I also tried running cygwin-x/XWin-server nothing happens.
I looked at the setup logs in cygwin/var/log/setup.log I can't see any error.
I tried to run the setup program a few more times reinstalling some of the packages I already had, that didn't help neither.
Any ideas how can I get that to work?
Here is the fix.
Go to you Windows Defender Security Center settings
Click on App & Browser Control
At the bottom click on the "Exploit Protection Settings" link
Go to "Program Settings" and click on the "Add program to
customize" -> "Choose exact file path"
Navigate to "C:\Program Files\Git\usr\bin\sh.exe" and add it
Override and turn off the following: Mandatory ASLR, Randomize memory allocations (Bottom-up ASLR)
Click "Apply" and now everything should work fine.
Also add these other binaries from the same folder: expr.exe, uname.exe, grep.exe, rm.exe
Good luck,
Gabriel
One of my colleagues has similar errors when openening the terminal from SourceTree (Mingw32), and also got errors when trying to pull, rebase, etc (anything not local). He solved it by uninstalling Sourcetree, using CCleaner to clean his registries (not sure if this was required), rebooted and installed Sourcetree again.
I know this is slightly different from the problem described by the OP, but it might still be solvable by un/re-installing and cleaning of registries, and this might also help future people finding this question with the Sourcetree issue (like I did).
Edit:
Another colleague had the issue as well, and he managed to fix it merely with a restart without any un/re-installation or using CCleaner.
I've been suffering similar problems a lot recently. I've been unable to determine the cause, whether it's due to a recent Windows7 patch or an update in the latest cygwin. I'm in a tightly controlled corporate environment with only limited elevated rights, a lot of anti-malware and encrypted drives. I'm using 32-bit Cygwin at present.
Issues for me began after I installed Git and Git-Svn packages, which required Perl and upgraded various other Cygwin packages as well.
Rebasing using rebase-trigger or rebaseall did not solve the issue for me. Neither did re-installing and setup repeatedly raised errors in the post-install pahse when trying to do the rebase itself.
My first success was by downgrading Perl to the previous version, ie. down to 5.22.1.2 from 5.22.2.1. After a couple of weeks the error returned, perhaps after a compulsory windows update and reboot.
My latest success has been achieved by ignoring the dash/rebaseall script and running rebase.exe directly as follows:-
Create a file which lists all cygwin .dlls in the /bin directory except cygwin1.dll and cyglsa.dll ie.
$ cd /bin
$ ls -1 *.dll | egrep -v '(cygwin1|cyglsa).*\.dll' >rebasedlls.txt
Close all cygwin terminals, if you have any services running which use cygwin ensure that those are stopped also. Check TaskManager and kill processes if necessary.
Open a cmd.exe window (it may help to use whatever elevated rights you can muster), change to the windows path of your cygwin /bin directory (ie. the windows directory of cygpath -wa /bin).
Use rebase.exe directly to find the base address of the cygwin1.dll file:
C:\apps\cygwin\bin> rebase.exe --info cygwin1.dll
/usr/bin/cygwin1.dll base 0x61000000 size 0x00500000
Using that base address and the size as a guide I chose the next whole value up as my rebase base address, 0x62000000. No particular reason for this, just a hunch. (The rebaseall script uses 0x70000000).
Use rebase.exe to fix all the .dlls listed in the file from step (1):
C:\apps\cygwin\bin> rebase -b 0x62000000 -4 -n -v -t -T rebasedlls.txt
So far, so good, my Cygwin is back to a working state again.
From https://chromium.googlesource.com/chromium/src/+/master/docs/cygwin_dll_remapping_failure.md
Handling repeated failures of rebaseall to allow cygwin remaps
Sometimes DLLs over which cygwin has no control get mapped into cygwin
processes at locations that cygwin has chosen for its libraries.
This has been seen primarily with anti-virus DLLs. When this occurs,
cygwin must be instructed during the rebase to avoid the area of
memory where that DLL is mapped.
Background
Some background for this is available on
http://www.dont-panic.cc/capi/2007/10/29/git-svn-fails-with-fatal-error-unable-to-remap/
Because of unix fork semantics (presumably), cygwin libraries must be
mapped in the same location in both parent and child of a fork. All
cygwin libraries have hints in them as to where they should be mapped
in a processes address space; if those hints are followed, each
library will be mapped in the same location in both address spaces.
However, Windows is perfectly happy mapping a DLL anywhere in the
address space; the hint is not considered controlling. The remapping
error occurs when a cygwin process starts and one of its libraries
cannot be mapped to the location specified by its hint.
/usr/bin/rebaseall changes the DLL hints for all of the cygwin
libraries so that there are no inter-library conflicts; it does this
by choosing a contiguous but not overlapping library layout starting
at a base address and working down. This process makes sure there are
no intra-cygwin conflicts, but cannot deal with conflicts with
external DLLs that are in cygwin process address spaces
(e.g. anti-virus DLLs).
To handle this case, you need to figure out what the problematic
non-cygwin library is, where it is in the address space, and do the
rebase all so that no cygwin hints map libraries to that location.
Details
Download the ListDLLs executable from
sysinternals
Run it as administrator while some cygwin commands are running.
Scan the output for the cygwin process (identifiable by the command) and for
DLLs in that process that do not look like cygwin DLLs (like an AV). Note
the location of those libraries (there will usually only be the one).
Pick an address space location lower than its starting address.
Quit all cygwin processes.
Run a windows command shell as administrator
cd in \cygwin\bin
Run ash /usr/bin/rebaseall -b <base address> (This command can also take a
-v flag if you want to see the DLL layout.)
That should fix the problem.
Failed rebaseall
If you pick a base address that is too low, you may end up with a broken cygwin
install. You can reinstall it by running cygwin's setup.exe again, and on the
package selection page, clicking the "All" entry to Reinstall. You may have to
do this twice, as you may get errors on the first reinstall pass.
I have Administrator access to my PC. For me the solution to this was to run the Cygwin session as Administrator -- right the icon, run as administrator, as shown here:
After running as Administrator the first time, new Cygwin sessions started up without hassle.
There is a rebase utility that triggers the rebase as post-setup phase.
From dash or bash:
/usr/bin/rebase-trigger full
close all process and run again setup-x86_64.exe.
uninstall it,
and install the software for 32-bit.
I restarted 3 times, and then it was fine. wtf Windows 7
This exact same error message has various causes, not all of them related to setup-x86_64.exe, although I have seen it in that context as well. But if rebaseall didn't fix your problem, here's a suggestion that might work.
In the case I saw this morning, it turned out to have been caused by having a couple of processes that continued to run after I exited the mintty terminal emulator. My hunch is that these zombie processes prevent the console from being recycled. In my case, the two processes were determined experimentally, by reviewing a list of running processes for stray processes that are no longer needed. I found the two processes that were blocking me by reviewing the list of running tasks.
C:\WINDOWS\system32>tasklist | grep Console
CobraWinLDTP.exe 31844 Console 1 43,600 K
geckodriver.exe 52640 Console 1 32,164 K
C:\WINDOWS\system32>taskkill /F /PID 31844
SUCCESS: The process with PID 31844 has been terminated.
C:\WINDOWS\system32>taskkill /F /PID 52640
SUCCESS: The process with PID 52640 has been terminated.
I saw on some other stackoverflow questions that git is often the zombie process that causes this symptom (for some users). Unfortunately, any residual process that survives after your console session is closed can cause this problem, so you have to experiment.
Go to The Task manager
Kill 'Git for Windows' process
Reopen your git bash
It seems that all is working fine.
NOTE: In case you don't find 'Git for Windows' process and still have to face the same just kill 'Node.js: Server-side JavaScript' process instead
If you have turned Force randomization for images (Mandatory ASLR) on in Exploit protection of Windows Security, then you can turn it off by selecting Use default (Off) to address this issue.
My instance of this problem was also related to having turned on 'force randomization for images' in the Windows Security exploit protection settings.
After you change the setting back to the default off position and reset, you will have to run Git as an administrator in order to effect directory changes which apparently require elevated permission.
I wasn't able to determine a way to allow that setting to be turned on and not get this issue with Git though I played around with it for a while unsuccessfully.
Turning even optional security features off to get a single program working seems like a last resort option to me. However, this isn't just any program either.
Ember-cli is building very slowly with ember server on windows.
Build successful - 13126ms.
Slowest Trees | Total
-------------------------------+----------------
TreeMerger (vendor) | 3154ms
TreeMerger (stylesAndVendor) | 2051ms
TreeMerger (appAndDependencies) | 1914ms
StaticCompiler | 1791ms
This is in contrast to the same project building in less that 1 second on a linux box.
There are two big culprits:
Real time file system scanning or protection
Realtime-protection from Windows Defender (also know as Microsoft Security Essentials in win7)
Windows Search Indexing
Antivirus scanning
Unused files in your bower_components folder
Real time Scanning
During a build numerous files are generate in the ./tmp folder of the ember project, both the indexer and the realtime-protection make additional reads of each file which adds a significant amount of additional file I/O operations.
The fix is to:
exclude node.exe and/or the ./tmp folder from realtime-protection, and
exclude the folder from indexing.
Disable real-time antivirus scanning
This should get your build time down to a couple seconds. Additional speed improvements for Windows are being investigated continuing to be investigated in relation to Broccoli's handling of the build process.
Managing unused bower files
Having lots of files in the bower_components is the biggest culprit.
I wrote up a script, clean-ember-cli.js, that deletes everything but ember-cli dependancies, and anything imported in the Brocfile.js. I'm getting back to around 5 second build times.
Update
Reports are that running console as admin also helps.
Official recommendation from ember-cli to improve its performance on windows
Install ember-cli-windows with node using the below command
npm install -g ember-cli-windows
Run the following command on your project root folder
ember-cli-windows
mind one important thing... and I didn`t found out in any forum... if you are working with a laptop and you are not connected with AC, windows may run in low performance mode to keep battery. This cause ember build proyects 4 times slower
Using ember-cli 1.13.13 with a command prompt running as an administrator fixed it for me
In addition to answers provided above run
ember s
in powershell in admin mode. This enables symlinks which are not enabled by default in windows. Having symlinks creates a flatter node_modules folder which results in faster running times.
(Source)
From build 20262 Windows 10 have WSL 2.
This is Linux on your machine and gives us performance as good as
on Linux.
Get last Ubuntu from Microsoft store.
Do not use /mnt/ folder for repo because of slow speed,
use ~ folder.
Connect with terminal on Ubuntu and clone your repository.
cd ~
git clone your-repo
install node version manager and node
Install ember-cli and start server.
npm install -g ember-cli
cd ~/your-repo
npm i
ember serve
In VSCode install plugin "Remote - WSL", open your repo and start development.
With Windows 7 I got a 50% improvement by turning off Encrypting File System (EFS) for the project's /tmp directory. (right-click Properties->Advanced->Encrypt contents...)
For later versions of Ember CLI running in admin mode as mentioned here and suggested by D-Go in his answer seems to be the way to go, assuming your company allows this.
If like me you are using GIT Bash to run Ember you may be interested in how to set it up to automatically run in admin mode here
All,
Am trying to get Node.js to work on Vista machine.
I installed Cygwin (as per the Github instructions) which appears to have been installed correctly. However, none of the commands are executing.
Are there any tutorials for the stages after the Cygwin installation?
PROBLEM: When any command is executed, I get 'Bash: command not found' error.
Not even command like 'c:\cygwin\bin' is executing.
When I type 'user' in cygwin command prompt, I get 'ntvdm has encountered an system error. Parameter incorrect'.
I thought the above error may be due to the firewall, disabling the firewall did not have any effect, running the program with admin rights also did not change the results...
Am confused and would love to get some guidance on what steps to go with next on getting Node.js up and running on a Windows Vista machine.
Many thanks,
UPDATE1:
We managed to make a bit more progress. It appears that we had not installed all the relevant files related to Cygwin. Upon re-download and reinstalled, it ran well, however, we have driven into another error. Error we get:
How to compile/install node.js(could not configure a cxx compiler!) (Ubuntu).
We followed the instructions as per the above thread (3rd post from top for Windows machines), however, we are still stuck at the same error.
Any guidance please?
Have you tried just using the Windows self contained binaries? http://node-js.prcn.co.cc/ This way you actually don't need to bother with Cygwin.
At first, i tried it your way too, using Cygwin. After smashing my head for the 10th time against a wall i just stopped trying and found a much cleaner solution.
I'm using VirtualBox running a Debain guest system to locally develop on my Windows 7 machine. Using VirtualBox, you can easily set up shared folders or port forwarding for node apps between your Windows machine and your Debian guest system.
Since you are using a plain Linux-system, all the compiling-pain is blown away.
If you plan to run node.js in production on a windows system: don't. I hardly believe node.js will be ever stable enough on windows-based systems using MINGW/Cygwin...
People seem to run into problems with Cygwin because they think that they are using a Windows machine.
If you install Cygwin, and open a bash shell prompt using the Cygwin icon, you are now in a UNIX environment and everything works the same as it would on UNIX. That includes building node.js.
I think you added some info to the question and I can see your problem. Yes, normally on Cygwin it has been possible to build node.js just as you would on any UNIX system, but that is no longer possible on Windows 7. Before running ./configure you have to:
Close all cygwin apps.
Double-click on C:\Cygwin\bin\ash.exe
Run ./rebaseall and when it completes, run ./perlrebase.
exit from the ash shell window.
At this point Cygwin will be back to normal and you can ./configure and make install.
I'm reinstalling everything on my machine, and amongst those is Cygwin. I'm trying to avoid reinstallation, partly because I don't even know what it is that I've installed. Can I just move the Cygwin directory from one machine to another and expect everything to work, or are there some other important settings that I need to move as well?
As far as I saw, it's pretty self-contained, but one never knows.
Yep! Go for it. You won't encounter any problems.
You can just copy the entire cygwin directory to your new machine, open up the cygwin shell and everything (as long as you are only calling cygwin-internal programs and stuff that's within the path) will just work as if you you are working on your old machine.
The only thing you'll loose is the directory where the "already downloaded and compressed" packages for a possible re-installation are stored. Fortunately this directory is optional, so no problem for migration to another platform. You could copy that directory as well, but most likely all the packages that you have are outdated anyways and a run of setup.exe would fetch the new versions anyway...
Btw - since someone said exactly the opposite some real-life experience: I use this feature quite often with success. I've copied my cygwin dir to USB-sticks and used it on friends computers. I also copied it to the laptop of my fiance when we go to holidays and take a laptop with us.
It always worked without any problems....
The short answer is: No, you can't copy the whole Cygwin folder. You just copy the configuration files(bash files, vim file, etc.) you need.
The long answer is: If you copy the whole Cygwin folder, it may work in some case, and may not in some other case.
The reason is: you will lose linux file mode when copying files on Windows. And that will cause a lot of troubles. However, you may not have the troubles when you use Cygwin just like a common Windows Program(which means you don't care file mode and anything related), and run it as Windows Administrator(which is not required when Cygwin is installed as usual).
BTW: you can export the packages you installed by cygcheck.exe -c and install them on the new Cygwin. You can also install/update Cygwin packages by Cygwin's setup-x86_64.exe in command line like:
setup-x86_64.exe -q -P package1,package2,package3
No, you have to reinstall it from the cygwin installer, sorry!
Most importantly you'll want to copy everything from your home directory (default is c:/cygwin/home/) especially anything w/ a "." in front of the filename.
As for individual application preferences, etc., you may lose those -- but if you do the reinstall while you still have access to your old machine -- you can probably get to 90% of your previous install without too much trouble.
My experience with copying from one cygwin64 (I don't think there is a difference) to another machine is that all of the symbolic links got crushed:
As an example:
What used to be /usr/bin/cc -> /usr/bin/gcc.exe (or something like that)
After the copy /usr/bin/cc became a text file containing the string:
!<symlink>/usr/bin/gcc.exe
My method of copy was merely cp -r /cygwin/c/cygwin64 <dest>
My dest was a FAT32 FS, but I don't think that had anything to do with it.
There were also characters 0x00 and 0xFF sprinkled among many of these 'text' files so that they appeared to be binary.