composer is usually very slow, and it provide no usual element to represent its progress. I always have to use -vvv option. Is there any way to make it always in verbose mode?
This can be done easily on Linux with an alias.
alias composer="composer -vvv"
You can make this permanent by appending this line to your .bash_profile or equivalent in your home directory.
If you are running on Windows, you can create a batch file wrapper in your PATH, something like:
#echo off
composer -vvv %*
Both of these assume that Composer is in your PATH already - if this is not the case, you'll need to prefix it with the full path.
Related
I would like to have shell aliases that effectively are folder-aware, so that when running a command in a folder containing a .php file, the contents of which are just 8.1 for example, the corresponding binary is run.
alias php8.0='/opt/homebrew/Cellar/php#8.0/8.0.26/bin/php'
alias php8.1='/opt/homebrew/Cellar/php/8.1.13/bin/php'
alias phpv='php"$(cat .php)" -v'
The above however, when running phpv returns an error of command not found php8.1. Whereas running php8.1 -v on its own works correctly.
Generally, alias is for simple text that shortens something you type often.
alias ll=`ls -l`
If you're doing anything more complicated that that, use a function, not an alias.
As an exercise, to keep it close to your otiginal idea - set whichever you prefer as the default in your PATH, but when you want a structure to override it, then instead of a local hidden file with a number that gets hack/parsed on the fly, create a local symlink to the one needed in that folder. While it's a security concern, you could just set the local directory in your path and be done. A function can lessen that security concern by localizing that change to the scope of the specific function call.
php() { [[ -L ./php ]] && local PATH=".:$PATH"; # only localize if local symlink exists
local php=$(which php --skip-alias --skip-functions); # variable gets PATH-relevant version
if [[ -x "$php" ]] # checks for relevant success
then "$php" "$#" # runs appropriate version
else "No PHP available." # reports if none
fi
}
This falls down when you start needing entire subdirectory structures that need one version or the other, because now you have to put that symlink (or .php file, or whatever) in every folder in that structure, and it's a mess and a maintenance nightmare.
A better solution would be to set up as clean a structure as possible, and try to put (only) the highest/shortest directory paths at the top of all projects and miscellaneous errata that need alternate versions into a lookup.
phpv() {
local php='php'
local -A altv=(
[/first/dir/to/edit]="/opt/homebrew/Cellar/php#8.0/8.0.26/bin/php"
[/next/dir]="/some/other/version/bin/php"
[/next/dir/for/edits]="/opt/homebrew/Cellar/php#8.0/8.0.26/bin/php"
)
d="$PWD" # set longest path to check
while [[ -n "$d" ]]
do if [[ -n "${altv[$PWD]}" ]] # if there's an override
then php="${altv[$PWD]}" # override the varible
break # get out, using the longest match
fi
d=${d%/*} # check one directory higher for an override
done
$php" "$#" # runs appropriate version
}
This way, if you run phpv -v (or with any other set of arguments) it should check where you are the list of places that get overrides, using the longest match, which allows different overrides in subdirectories, but only requires an override to list the highest, shortest paths that need to use an alternate version. If no overrides are found for your current directory or any parent, then you default to whatever is set in your PATH.
Using the example paths I included, if you are in /usr/bin or /etc/ or /first/dir/to/delete or anywhere else that exactly doesn't SOMEWHERE along its parentage, it will default to your PATH. If you are in /first/dir/to/edit/today it will match /first/dir/to/edit as a parent (any subdir of that path will) and use /opt/homebrew/Cellar/php#8.0/8.0.26/bin/php. If you are in /next/dir/for/lunch it will match /next/dir as a parent and use /some/other/version/bin/php, but in
/next/dir/for/edits it matches the longer path first and uses /opt/homebrew/Cellar/php#8.0/8.0.26/bin/php instead.
Hope all that helps inspire a useful solution.
I'm looking through the documentation, but I'm not seeing any option to change the working directory used when running tests.
I'm using PhpUnit as it's included in Laravel. I want to be able to run vendor/bin/phpunit from my project's root directory, and have it run using the /public directory as the working directory.
I tried running ../vendor/bin/phpunit from the /public, but since the phpunit.xml file isn't in the public directory and I don't want to specify my config file path every time, that won't work.
Is there something I can add to my phpunit.xml file to tell it to run tests using the /public directory as the "cwd" (current working directory)?
Based on the feedback I received in the comments and the documentation, I determined the following:
It's probably not possible to change the cwd that phpunit uses by default (well, it's possible in PhpStorm, but not the command line without writing some kind of wrapper script)
Code that depends on being run from a specific directory is not a good idea.
What I had was some code in one of my classes like this:
$var = file_get_contents("../some_file.json");
This works fine -- until you try to add unit tests. The web server runs using the /public directory as the cwd, while phpunit will run using the root directory.
Rather than trying to force phpunit to always use a particular cwd (/public), I decided it's probably best to remove relative paths from the code that rely on a consistent cwd. So the line above becomes:
$var = file_get_contents(base_path("some_file.json"));
I didn't want to change production code that was already working just to get some tests in place, but this change seemed insignificant enough. (and it's an improvement anyway)
Well, you'd have to do the actual chdir in PHP, but you can define a bootstrap script in the XML (<phpunit bootstrap="./bootstrap.php">) and have that change the working directory.
Alternatively, you can put a setUpBeforeClass function into your test class that changes the working directory.
the code is stored in /var/www/abc -- "CodePath"
when running gitlab-ci (runner), the code is called via /home/gitlab-runner/builds/4v8bC1n9/0/_gitlabgroup_/_gitprojectname_/abc -- "RealPath"
I'm using a local runner and a shell execution.
when I use the realpath() function in my php code, it still shows the "CodePath" when using gitlab ci runner, instead of "RealPath".
How can I get the "RealPath" integrated in my code, or reconfig GitLab to use the "CodePath" instead?
The runner cli options are documented here: https://docs.gitlab.com/runner/executors/shell.html#overview
The path where the job is run and your sources are cloned into is available in the environment variable:
CI_PROJECT_DIR
The full path where the repository is cloned and where the job is run. If the GitLab Runner builds_dir parameter is set, this variable is set relative to the value of builds_dir. For more information, see Advanced configuration for GitLab Runner.
You did no state how you use realpath(path)...
Whilst a path must be supplied, the value can be an empty string. In this case, the value is interpreted as the current directory.
So maybe you hardcode chdir('/var/www/abc'); somewhere?
When you do chdir(getenv('CI_PROJECT_DIR')); before you call realpath() - it should use the CI directory. Assuming you use realpath without a parameter.
Also: maybe you can make some changes and use one of the the built in constants for the current directory: https://www.php.net/manual/en/language.constants.predefined.php
Thanks to madflow's mentioning of the variable I managed to figure out the following:
runners specific configuration files exist and can be configured as described here
I needed to do these things:
specify enable the [runners.custom_build_dir] section in the config.toml
[[runners]]
builds_dir = "/var/www/abc"
[runners.custom_build_dir]
enabled = true
(boolean not in quotes)
specify a variable in my yml
variables:
GIT_CLONE_PATH: $CI_BUILDS_DIR/
on os level there was some privilege setting for the dir required, where I went for quick and dirty 777 on my local machine
I have a php application that relies on several classes to function properly. If I take one of the application's class files
/my/folder/class.php
then move it somewhere else
mv /my/folder/class.php /my/other/folder/class.php
then in its place inside of
/my/folder/
I create a symlink to it called class.php via
ln -s /my/other/folder/class.php /my/folder/class.php
I would expect my application to be unaffected, but instead this is breaking it. I know the symlink is valid since at the command line I can do
nano /my/folder/class.php
and everything looks as I would expect it to. Am I missing something fundamental about the behavior of symlinks, and/or how apache or php processes them? Is it changing the working directory or $_SERVER['DOCUMENT_ROOT']? I can not figure out why this would have any affect on my application.
I am using Apache server in CentOs.
Thanks!
The only difference would be if you are using require_once or include_once and you are mixing the symlink path with the real file path. In this instance, the X_once is going to think those files are different and load it twice (which will of course cause problems if you define any classes or functions).
Would probably need an actual error message to guess any further.
Here is the situation.. I have some classes that are in one project... My main code is in another project... and i split this up because i am using GIT as my SCM... So when i debug my main code... i would like to step into the classes and debug them, but xdebug won't let me step into them... and i assume its because the classes are in another project... any ideas?
Thanks in advance...
I've run into this as well. I am going to assume that the way your projects look when they are deployed is that the classes in the separate project are copied into some directory somewhere in the main code.
Let's assume the separate project contains only one class, Foo, for simplicity's sake. Let's assume, too, that Foo is present in the deployed "main code" in the directory and file /maincode/external/lib/Foo.php. Finally, let's assume that /maincode/external/lib exists as a directory in your version-controlled "main code" project, and that it contains only a place-holder file and is otherwise empty.
First, use one of the many methods git provides to ignore the contents of the /maincode/external/lib directory in your NetBeans project directory for that project. We're going to make it look like it contains some stuff, and we don't want this directory, that is otherwise supposed to be empty, to get changes committed to it by mistake.
Now that it is ignored, make a symbolic link in that directory to Foo.php over in the other project. In Unix, you want the ln command, e.g.
ln -s /path/to/project/files/MyFooProject/Foo.php Foo.php
In Windows, you are looking for the mklink command, e.g.
mklink Foo.php C:\path\to\project\files\MyFooProject\Foo.php
Give NetBeans a moment or two to think about it (or force the issue by invoking the "Scan for external changes" command in the "Source" menu), and you should see Foo.php show up in the "maincode" project where you made the symbolic link.
Now, when you are tracing through execution and need to step into Foo.php to see what the Foo class is doing, you will step into the one that is in the "maincode" project. Since it is a symbolic link over to the file in the "MyFooProject" project, however, any chanes you make will be reflected over there.
Just be sure to unlink everything (the normal rm commmand in Unix, and the usual del command in Windows, but in the directory where the symbolic link is!) when you are through. Also, if there were things in the directory that you ignored that you want to be able to commit, then un-ignore that directory.
If you need to do this for more than just one file, then you can link whole directories. If, instead of the above, you normally copy the contents of "MyFooProject" into the directory /maincode/external/lib/myfoo/ in the deployed version, then just link the appropriate directory like you did the file above. In Windows, for example,
cd \path\to\project\files\maincode\external\lib
mklink /D myfoo C:\path\to\project\files\MyFooProject
That will make a symbolic directory link. It has been a while since I did anything like that on Unix, so I don't remember the exact command for the same thing on that OS (or if symbolic directory links are even possible on Unix). Once the directory is linked, you should see the new directory plus all of the files and subdirectories show up in your NetBeans "maincode" project, ready for your execution-tracing pleasure.
Again, remember to unlink and un-ignore everything once you are done, lest you wake up the next morning to find yourself confused. :) To unlink the directory in windows...
cd \path\to\project\files\maincode\external\lib
rmdir myfoo
and it should unlink. (Just be careful when you are deleteing and rmdir'ing that you are doing it to the symbolic link!)