profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/Waples/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Florian B. Waples @ogd-software Apeldoorn, Netherlands https://www.freyrsvin.nl { 'Florian': { 'Life': ['Just going with the flow'], 'Work':['Cloud Engineer', 'DevOps Engineer','Python Developer'], 'Study': ['Flask', 'Serverless']}}

tldr-pages/tldr 33277

📚 Collaborative cheatsheets for console commands

Waples/podcrow 2

pythonic podcast downloader

Waples/Waples_ 1

Building a static website generator for use with AWS S3 static website hosting for my personal stuff.

ogd-software/botocore 0

The low-level, core functionality of boto 3.

Waples/3d-prints 0

A collection of my best and worst 3D designs for printing

Waples/ArchDwmInstall 0

Fresh install of Arch, which syncs my dotfiles from repo

Waples/aur4all 0

Arch Linux AUR searcher (and maybe future AUR Helper)

Waples/aws-automation 0

Some python (boto3) scripts to use with CI/CD pipelines.

Waples/banking 0

(Re-)Creating a PayPal~ish banking system in Python. (Maths is hard).

Waples/calculator 0

A node.js demo application

Pull request review commenttldr-pages/tldr

sdcv: add page

+# sdcv++> StarDict console version. Command line dictionary client.+> Dictionaries are provided separately.+> More information: <https://manned.org/sdcv>.++- Start sdcv interactively:++`sdcv`++- List installed dictionaries:++`sdcv --list-dicts`++- Display a definition from a specific dictionary:++`sdcv --use-dict {{dictionary_name}} {{search_term}}`++- Lookup definition with fuzzy search:++`sdcv {{search_term}}`++- Lookup definition with exact search:++`sdcv --exact-search {{search_term}}`++- Lookup definition and get json output:++`sdcv -j {{search_term}}`++- Look in specific directory for dictionaries:++`sdvc --data-dir {{path/to/directory}} {{search_term}}`++- Display help:++`sdcv --help`

I think most of the command line utilities accept the switch -h or --help. In my opinion we should only keep those that have anything apart from this (I do not have an example handy)

258204

comment created time in 31 minutes

startedkopia/kopia

started time in an hour

push eventtldr-pages/tldr

Benjamin Grant

commit sha 4232eb56cbf6e3646c5c85c08ba5b6c2d9b23ba5

convert: add .ico example (#6143)

view details

push time in 3 hours

push eventtldr-pages/tldr

Benjamin Grant

commit sha 4232eb56cbf6e3646c5c85c08ba5b6c2d9b23ba5

convert: add .ico example (#6143)

view details

push time in 3 hours

PR merged tldr-pages/tldr

convert: add .ico example page edit

A common command I use a lot, felt it could be useful here

+4 -0

4 comments

1 changed file

GRA0007

pr closed time in 3 hours

pull request commenttldr-pages/tldr

Write contributing-guides/alias-pages.md

@SethFalco I don't think this template will change very often and I don't really like the idea of having another folder in the repository.

marchersimon

comment created time in 4 hours

release home-assistant/core

2021.6.6

released time in 5 hours

pull request commenttldr-pages/tldr

convert: add ico convert example

Thanks everyone, honestly I just saw a missing bit of info and did everything through the github ui, I'm surprised it tried to merge into master if your branch is called main. I'll fix up those issues too :)

GRA0007

comment created time in 6 hours

Pull request review commenttldr-pages/tldr

git-verify-tag: add page

+# git verify-tag++> Check for GPG verification of tags.+> If tag isn't signed with -s when made, you will get an error regardless of signing.

with -s without the full command doesn't have enough sense, also I think should be a gitconfig setting to auto sign tags.

CleanMachine1

comment created time in 8 hours

Pull request review commenttldr-pages/tldr

aws-s3api: add page

+# aws s3api++> Create and delete Amazon S3 buckets and edit bucket properties.+> More information: <https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/index.html>.++- Create a bucket:++`aws s3api create-bucket --bucket {{bucket_name}}`++- Delete a bucket:++`aws s3api delete-bucket --bucket {{bucket_name}}`++- List buckets:++`aws s3api list-buckets`++- List the objects inside of a bucket and only show each object's key and size:++`aws s3api list-objects --bucket {{bucket_name}} --query '{{Contents[].{Key: Key, Size: Size}}}'`++- Add an object to a bucket:++`aws s3api put-object --bucket {{bucket_name}} --key {{object_key}} --body {{path/to/file}}`++- Download object from a bucket (The output file is always the last argument):++`aws s3api get-object --bucket {{bucket_name}} --key {{object_key}} {{path/to/output_file}}`++- Apply an Amazon S3 bucket policy to a specified bucket:++`aws s3api put-bucket-policy --bucket {{bucket_name}} --policy file://{{path/to/bucket_policy.json}}`++- Download the Amazon S3 bucket policy from a specified bucket:++`aws s3api get-bucket-policy --bucket {{bucket_name}} --query Policy --output {{json|text|table|yaml|yaml-stream}} > {{path/to/bucket_policy}}`

Alphabetic order:

`aws s3api get-bucket-policy --bucket {{bucket_name}} --query Policy --output {{json|table|text|yaml|yaml-stream}} > {{path/to/bucket_policy}}`
258204

comment created time in 8 hours

Pull request review commenttldr-pages/tldr

aws-cur: add page

+# aws cur++> Create, query, and delete AWS usage report definitions.+> More information: <https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cur/index.html>.++- Create an AWS cost and usage report definition from a JSON file:++`aws cur put-report-definition --report-definition file://{{path/to/report-definition.json}}`

Ok, if smb:// doesn't work this is ok then.

258204

comment created time in 8 hours

Pull request review commenttldr-pages/tldr

MAINTAINERS: add @mfrw to org

 If you are an owner of the organization, you can see an automated list   [10 May 2021](https://github.com/tldr-pages/tldr/issues/5919) — present - **Seth Falco ([@SethFalco](https://github.com/SethFalco))**:   [19 May 2021](https://github.com/tldr-pages/tldr/issues/5993) - present+- **Muhammad Falak R Wani ([@mfrw](https://github.com/mfrw))**:+  [6 September 2018](https://github.com/tldr-pages/tldr/issues/2306) — [21 June 2021](https://github.com/tldr-pages/tldr/issues/6142) - Owen Voke ([@owenvoke](https://github.com/owenvoke))   [11 January 2018](https://github.com/tldr-pages/tldr/issues/1885) — [26 August 2018](https://github.com/tldr-pages/tldr/issues/2258)

I think this is the correct order:

- Owen Voke ([@owenvoke](https://github.com/owenvoke))
  [11 January 2018](https://github.com/tldr-pages/tldr/issues/1885) — [26 August 2018](https://github.com/tldr-pages/tldr/issues/2258)
- **Muhammad Falak R Wani ([@mfrw](https://github.com/mfrw))**:
  [6 September 2018](https://github.com/tldr-pages/tldr/issues/2306) — [21 June 2021](https://github.com/tldr-pages/tldr/issues/6142)
mfrw

comment created time in 8 hours

Pull request review commenttldr-pages/tldr

mklost+found: add page

+# mklost+found++> Create a lost+found directory.+> More information: <https://manned.org/mklost+found.8>.
> More information: <https://manned.org/mklost+found>.
CleanMachine1

comment created time in 8 hours

PR opened tldr-pages/tldr

MAINTAINERS: add @mfrw to org community

closes: #6142

+4 -2

0 comment

1 changed file

pr created time in 9 hours

Pull request review commenttldr-pages/tldr

kscreen-console, kscreen-doctor: add page

+# kscreen-console++> KScreen Console is a CLI tool to query KScreen's status.+> More information: <https://manned.org/kscreen-console>.++- Show all outputs and configuration files to attach to a bug report:++`kscreen-console bug`++- Show paths to KScreen configuration files:++`kscreen-console config`++- Show display output information:++`kscreen-console outputs`++- Monitor for changes:++`kscreen-console monitor`++- Show the current KScreen configuration in JSON:++`kscreen-console json`++- Display help on command-line options:

Let's just go with Display help as @navarroaxel suggested, and we can discuss whether or not to include --help examples in a different issue (I think that's coming soon :)

SethFalco

comment created time in 9 hours

pull request commenttldr-pages/tldr

kscreen-console, kscreen-doctor: add page

Whoa, sorry, totally lost track of this.

SethFalco

comment created time in 9 hours

issue commenttldr-pages/tldr

Add organization member: @mfrw

Invite sent, awaiting reply

@mfrw, can you open a PR to update the MAINTAINERS.md please? :-)

Sure :)

bl-ue

comment created time in 9 hours

pull request commenttldr-pages/tldr

sdcv: add page

There were some conflicting changes requested. I modified the file to address them. Let me know if you want any additional changes.

258204

comment created time in 11 hours

Pull request review commenttldr-pages/tldr

sdcv: add page

+# sdcv++> StarDict console version. Command line dictionary client.+> Dictionaries are provided separately.

How about "StarDict command-line version, dictionary client. Dictionaries are provided separately from the client. "

258204

comment created time in 11 hours

pull request commenttldr-pages/tldr

kscreen-console, kscreen-doctor: add page

Hi all! This thread has not had any recent activity. Are there any updates? Thanks!

SethFalco

comment created time in 11 hours

fork c02y/vim-autoformat

Provide easy code formatting in Vim by integrating existing code formatters.

fork in 11 hours

Pull request review commenttldr-pages/tldr

sdcv: add page

+# sdcv++> StarDict console version. Command line dictionary client.+> Dictionaries are provided separately.

I want to include"StarDict command-line version" somewhere, because that's what the acronym is.

258204

comment created time in 11 hours

issue commenttldr-pages/tldr

Localization of Numbers

In terms of result/usage, my favorite is Option 3. However, I concede to all points made above. I think it'd be nice to keep in mind the possibility. Perhaps it's something that could be considered when or if there are plans for other major changes that would impact clients.

I think Option 1 is a good candidate. That would also mean only one page would need update:

Benchmark a database with 10 clients, 2 worker threads, and 10,000 transactions per client: - pgbench.md

The only strong opinion I have is to reject Option 2, which both of us suggested separately at one point. After peeking into the language vs locale thing, it's not really a valid option for this. (Worth documenting the thought anyway.)

SethFalco

comment created time in 11 hours

issue commenttldr-pages/tldr

Localization of Numbers

Great writeup here. Option 3 looks interesting, but as mentioned here it has a number of issues:

  1. Additional custom syntax for pages
  2. Additional complexity for clients
  3. "Dumb" clients that don't support the new syntax results in displaying syntax that may be confusing for the user
  4. CommonMark doesn't (as far as I know) have any official syntax for this for us to follow either

To be honest, given that the longest number in all of our pages right now is only 6 digits I think that option 1 (no localisation) is probably the best option for now.

SethFalco

comment created time in 12 hours

issue openedtldr-pages/tldr

Localization of Numbers

I'm proposing that the style guide be updated to include how we approach localization of numbers, or if they should not be localized at all.

This discussion is only regarding numbers, not dates. This can be discussed further here if there is more to be said, but in general, it's believed using ISO/RFC standards like YYYY-MM-DD would be best, and avoids ambiguity between MM and DD.

You can see previous discussion on:

  • https://github.com/tldr-pages/tldr/pull/6069#discussion_r654959704
  • Matrix / Gitter

Option 1: No Localization

We should not have any localization applied at all. Instead, only the delocalized form should be used, like what we typically use in configuration files, command-line, or programming.

For example, the following would be invalid:

  • 1,337.42
  • 1.337,42
  • 1'337.42
  • 1 337.42

The correct form would be: 1337.42

This should be universally understood but all CLI users, but could make larger numbers harder to read. However, this may be a non-issue as the longest number in the repository is only 6 digits.

Specify the initial packet length (defaults to 65535 for IPv4 and 128000 for IPv6): - tracepath.md

Option 2: Localized to an Appropriate Locale

It has been suggested that we could hard-code a predefined locale with each language file.

For example:

  • en could use en-US, which is 1,337.42.
  • fr could use fr-FR, which is 1 337,42.

One problem with this approach is that languages and locales can't be mapped one-to-one. It suffers the same problem that happens when you try to map languages to country flags.

Languages can map to multiple countries, and this often also means multiple formatting rules. It's common for users to use one language, but another locale.

A real example, I use en-US for language, but en-GB for locale. (Only affects dates.) A hypothetical example, a Canadian that might use fr-CA for language, but en-CA for locale.

Even remaining in the same language.

  • en-ZA (South African English) is 1 337.42.
  • en-US (American English) is 1,337.42.

Option 3: Denote Localizable Numbers

I've suggested that we could denote localizable numbers, or numbers that can be localized for clients to handle localization using the system preference.

This would require the markdown files to have no localization at all, like in Option 1.

With this approach in mind, syntax would be required to denote which numbers can be localized to avoid falsely localizing numbers that shouldn't be.

For example, the following should not be localized:

  • Port numbers (3306, 8080)
  • Error/status/exit codes
  • Cryptographic Key IDs (if one happens to end with 0-9 only)
  • Date related numbers like the year (2019, 2021)

This means that all numbers that must be localized should be denoted somehow.

Clients can choose to strip out the notation, or interpolate the numbers with the locale of system. Clients may even choose to make it a toggle, or let users override the locale of the client to be separate from the system-preference.

The localization of numbers can be achieved easily, as it's built into most languages:

This approach leads to more maintenance burden, as new pages will have to adhere to wrapping said syntax around numbers. Clients would also require an update to handle the new syntax.

created time in 12 hours

delete branch tldr-pages/tldr

delete branch : bl-ue-patch-1

delete time in 12 hours

PR closed tldr-pages/tldr

Reviewers
CONTRIBUTING: remove emoticon documentation

Open for suggestions!

I'm thinking to remove this because it doesn't really feel right any more. It's also a bit personal, which seems inappropriate because the document is the voice of the whole community (or at least maintenance team).

+1 -1

10 comments

1 changed file

bl-ue

pr closed time in 12 hours

pull request commenttldr-pages/tldr

CONTRIBUTING: remove emoticon

Per the conversation on Gitter, I'm going to close this.

@waldyrious:

Hey @bl-ue, I will comment here for the time being, maybe later I might add more detailed feedback if the discussion is still ongoing. Honestly I don't have strong feelings either way. I like the emoji for the reasons others have pointed out, but it wouldn't bother me much if it were removed. Can you explain better why it bothers you that it's there? I'm not sure I understand the "voice of the community" concern. We do want to convey a friendly, informal, welcoming tone, and the emoji seems to help with that IMO. I'd actively support its removal only if some people interpret it as being sarcastic or passive-aggressive.

@bl-ue:

Of course, but too me emoji are better in message sent by obviously one person, whereas that document is written by a lot of people now. Back in March 2014 when it was written by Romain Prieto it was certainly him speaking for himself, but...

@sbrl:

That doesn't mean to say that the emoji can't echo the sentiment of the community as a whole

@waldyrious:

I think that may be just a cultural thing :) the wording of the document itself in no way conveys a personal voice, and I don't feel that using emojis gives that impression.

@waldyrious:

If others agreed that it did, I'd consider it worthwhile to rework that passage. I agree that the most we can encourage a collective voice in project docs, the better. But I don't think the emoji is working against that.

@bl-ue:

No, certainly not. It's difficult to put my finger exactly on what bothers me about it but I assure you it does so very little.

bl-ue

comment created time in 12 hours

pull request commenttldr-pages/tldr

CONTRIBUTING: remove emoticon

Other than discussing reasons, this should be simply voted for

bl-ue

comment created time in 12 hours

pull request commenttldr-pages/tldr

CONTRIBUTING: remove emoticon

Not quite. There's a "why I want to remove it" and a "why I don't want to remove it." 🙂

bl-ue

comment created time in 12 hours