Asked  7 Months ago    Answers:  5   Viewed   33 times

Possible Duplicate:
php How do I start an external program running - Having trouble with system and exec

how to open exe with php?
I had this idea and make hard to success it for several years,but failed at last. any one tell me a success method to do the job ?

<?php 
    if(isset($_POST['file_path'])){
        /* ------- 
            using "notepad++.exe" to open "test.php" file.
            or run a bat file which calling "notepad++.exe" to open "test.php" file.
            how to seting php.ini or firefox or any setting to do this job. 
            it is only for conveniently developing web page in my PC ,not for web servers
        ------- */
    }
?>

<form action="test.php" method="post">
    <input type="text" name="file_path" value="test.php"/>
    <button type="submit">open with notepad++</button>
</form>

This would create something like:

rendered HTML screenshot

 Answers

66

To launch a program on the computer which runs the webserver:

<?php
exec('"C:Program Files (x86)Notepad++notepad++.exe" "C:foo.php"');

The above will work on vista/win7 IF the webserver does not run as a windows service. For example, if you run apache and it automatically starts when your computer boots, you probably installed it as a service. You can check to see if apache shows up in the windows services tab/thingy.

If the webserver runs as a service, you'll need to look into enabling the "allow desktop interaction" option for the service. But otherwise:

An easy test using php's new built in webserver(php 5.4+). The key thing here is you manually start the server from a shell, so it runs as your user instead of as a service.

<?php
// C:myhtdocsscript.php
exec('"C:Program Files (x86)Notepad++notepad++.exe" "C:foo.php"');

start a webserver via a command window

C:pathtophp.exe -S localhost:8000 -t C:myhtdocs

Then in your browser http://localhost:8000/script.php

Wednesday, March 31, 2021
 
CAMason
answered 7 Months ago
82

Try this found here

//This input should be from somewhere else, hard-coded in this example
$file_name = '2013-07-16.dump.gz';

// Raising this value may increase performance
$buffer_size = 4096; // read 4kb at a time
$out_file_name = str_replace('.gz', '', $file_name); 

// Open our files (in binary mode)
$file = gzopen($file_name, 'rb');
$out_file = fopen($out_file_name, 'wb'); 

// Keep repeating until the end of the input file
while (!gzeof($file)) {
    // Read buffer-size bytes
    // Both fwrite and gzread and binary-safe
    fwrite($out_file, gzread($file, $buffer_size));
}

// Files are done, close files
fclose($out_file);
gzclose($file);
Wednesday, March 31, 2021
 
Kevin_Kinsey
answered 7 Months ago
56

The MDN top level page for addons used to give an overview over the different extension types (since FF57 only webextensions are supported).

Components.utils.import

this is for restartless/XUL (legacy) extensions.

const { Cu } = require("chrome");

this is for SDK extensions.

Neither will work in webextensions.

Unlike the other extension types webextensions are restrictive, they do not provide access to the low-level APIs that you can find all over the wiki.

So stick to pages that are under the webextensions hierarchy or standard web APIs when you're looking for documentation related to this extension type.

Wednesday, July 7, 2021
 
letrollpoilu
answered 4 Months ago
71

In modern operating systems, filenames very well might contain periods long before the file extension, for instance:

my.file.name.jpg

PHP provides a way to find the filename without the extension that takes this into account, then just add the new extension:

function replace_extension($filename, $new_extension) {
    $info = pathinfo($filename);
    return $info['filename'] . '.' . $new_extension;
}
Thursday, July 29, 2021
 
alioygur
answered 3 Months ago
34

Is there a good work-around"

I'd like to add onto Andrew's answer with some code examples.

As it turns out, promise chains destroy the browser's notion of what is and isn't triggered by a user input handler. Take the code below, for example:

document.getElementById('foo').addEventListener('click', event => {
  browser.permissions.request({origins: ["https://google.com/*"]})
})

This code works as expected. I originally assumed that it was Vue.js's unique event handling framework that was eating my "browser events", such as when you do <div @click="somefunc"></div>. This actually works just fine, as long as you put your permissions request in somefunc.

Now it gets fun. If you replace your permissions request with a promise that resolves and then does a permissions request, VIOLA!

Promise.resolve('foobar').then(foobar => {
    browser.permissions.request({origins: ["https://google.com/*"]})
})

Results in:

Error: permissions.request may only be called from a user input handler

Why does this happen?

I'm going to guess it has to do with stack traces. Firefox can't detect that a permission came from a stack with a user input event at the root if the permissions request happens in a promise chain.

I consider this to be a pretty egregious design choice. My app is large (>4K LoC) and to keep it simple I rely on promise chains to keep the spaghetti away. This has crippled my ability to write clean code, and as a result, I've moved from asking for optional_permissions and then prompting the user for permissions only when needed to just being overly permissive at the time of installation.

GG, Firefox.

Thursday, September 23, 2021
 
Savageman
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :