Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
Skip to content

Repository files navigation

Argument Handling for PHP CLI Scripts

This project aims to deliver a easy to use and free as in freedom php command component.

The build status of the current master branch is tracked by Travis CI: Build StatusLatest stable

The scrutinizer status are: code quality | build status

The versioneye status is: Dependency Status

Take a look on openhub.net.

The current change log can be found here.

Install

By Hand

mkdir -p vendor/net_bazzline/php_component_cli_arguments
cd vendor/net_bazzline/php_component_cli_arguments
git clone https://github.com/bazzline/php_component_cli_arguments .
composer require net_bazzline/php_component_cli_arguments:dev-master

Benefits

  • easy up handling of following kinds of arguments
    • flags (command -f|--force)
    • lists (command --foobar=foo | command -f=foo)
    • values values (command )

Example

Simple call run.php with tons of arguments like illustrated below.

php run.php --foo bar --foobar=foo --foobar="bar" -f="foo" -f=bar -b foobar foo -flag

Generates the following output.

arguments provided:
--foo
bar
--foobar=foo
--foobar=bar
-f=foo
-f=bar
-b
foobar
foo
-flag
flags provided:
foo
b
f
l
a
g
lists provided:
foobar
foo
bar
f
foo
bar
values provided:
bar
foobar
foo

Terms

All arguments are grouped into one of three types, flags, lists or values. Argument or parameter? I could not spot a major difference. When I think about parameters, my mind slipps into the domain of methods or functions, thats why I have decided to call them arguments. Furthermore, php.net calls the "argument list" also :-).

Flag

A flag is an argument that changes the behaviour of an command. It acts as a trigger so you can turn things on or off (best example in the world "-h|--help")

The position in a commandcall for a flag is not important, only the existence.

Valid flags are:

  • -f
  • --flag
  • -flag (shortcut for -f -l -a -g)

List

A list is an argument that contains multiple values per name.

This call

php example.php --my_list="argument one" --my_list="argument two"

would result into a list with the name "my_list" and two arguments, "argument one" and "argument two".

Lists are the most complex arguments. Like for flags, the position in a commandcall for a list usage is not important.

Valid Lists are:

  • -l=value
  • -l="val ue"
  • --list=value
  • --list="val ue"

Value

Values are straight forward arguments. You simple pass them to your command. Instead of a flag or a list, the position is important.

Valid values are:

  • value
  • "val ue"
php example.php "value one" "value two"

First value has the content "value one", second value has the content "value two".

php example.php "value two" "value one"

First value has the content "value two", second value has the content "value one".

Short Name and Long Name Notation

Flag and list arguments supporting short name ("-f") and long name ("--foo") notation. A short name is indicated by a single "-" while a long name is indicated by a double "-". The handling and the support of them is domain specific (and also a matter of tast). To merge the usage and the content for lists is not part of this component.

Why no Validation?

Validation is a complex topic. That's why I decided to not put it into the domain of this component.
It would complicate the code itself. I would have created a universal validation interface that would slow down the usage of this component. Furthermore, you would have to learn a validation expression language or would have need to write code that fits my validation interface but not your "way of coding".

At the end, what is validation all about?

  • check if a argument (flag, list, value) is passed or not
  • if it is passed validate the value or if it is allowed under that circumstance (if it is right to use flag "-f" while also flag "-b" is passed etc.)
  • if it is not passed but was mandatory, create a specific message or throw an exception (and the same for optional arguments)

To sum it up, validation is domain specific for the validation itself and the error handling. That's why I have decided to not support it deeply. The component supports your validation implementation with the methods "hasLists()", "hasList($name)" etc.

Since I won't write "never say never", if you have a smart idea or way to easy up validation, I'm open for an question or a pull request.

What about Optional Arguments?

Optional arguments underlying the same problems as validation. It is not that easy to implement in an elegant way. It is very special/domain specific (e.g. an argument is optional if flag "--xyz" is used, otherwise mandatory). Your code has to take care if an argument is passed or not anyways. Using the available "has..."-methods should be sufficient and generic enough.

API

API is available at bazzline.net.

Other Great Components

Final Words

Star it if you like it :-). Add issues if you need it. Pull patches if you enjoy it. Write a blog entry if you use it :-D.

About

free as in freedom free software php cli command thin wrapper to easy up usage and validation of command line arguments

Resources

Stars

2 stars

Watchers

4 watching

Forks

Releases

Packages

Used by

Contributors

Languages