I just assumed that nesting/inheriting settings would be a thing because of course it would

git_workspace/ ├── .vscode │ └── settings.json # global settings, my preferred ones ├── my-personal-projects/ │ └── project1/ │ └── .git/ └── company-projects/ ├── .vscode │ └── settings.json # local settings, overrides some of my personal ones ├── project2/ │ └── .git/ └── project3/ └── .git/

As you note, Activity diagrams inherently can include concurrency and timing. If you look at this example cribbed from Wikipedia, shown below, you can observe the section with two heavy horizontal bars, and two parallel activities of "present idea" and "record idea". That is read as "start these activities in parallel, and continue only when both are complete." Flowcharts can't express this within the notation. Practically, using activity diagrams lets you think clearly about concurrent processes. I think you'll find that anyone who can read a flowchart will quickly adapt.

Activity diagram spreads confusion by its own name, there must be a reason why nobody understand them and ask similar questions.

It might seem as a preference, but if we have a standardized language for describing software systems, Why do we use something else? This can lead to bad habit of overusing flowcharts. Activity diagrams are really simple. But if you decide to describe a more complicated aspect of the system or try to change the part you are describing, you might have to switch anyway. So just use UML and prevent confusion in the future.

assuming a standard is better because the standard says so, it is like that old while(1) infinite loop it is better not to enter.

When public clients (e.g., native and single-page applications) request access tokens, some additional security concerns are posed that are not mitigated by the Authorization Code Flow alone.

the OAuth 2.0 grant type, Authorization Code Flow with Proof Key for Code Exchange (PKCE).

it seems like a perversion of my beautiful REST/JSON server

Please note - any callback URL that you use with the POST oauth/request_token endpoint will have to be configured within your developer App's settings in the app details page of developer portal.

In the guide below, you may see different terms referring to the same thing.

If the Client is a Single-Page App (SPA), an application running in a browser using a scripting language like JavaScript, there are two grant options: the Authorization Code Flow with Proof Key for Code Exchange (PKCE) and the Implicit Flow with Form Post. For most cases, we recommend using the Authorization Code Flow with PKCE because the Access Token is not exposed on the client side, and this flow can return Refresh Tokens.

Is the Client absolutely trusted with user credentials?

Which OAuth 2.0 Flow Should I Use?

If the Client is a regular web app executing on a server, then the Authorization Code Flow is the flow you should use. Using this the Client can retrieve an Access Token and, optionally, a Refresh Token.

The first decision point is about whether the party that requires access to resources is a machine. In the case of machine-to-machine authorization, the Client is also the Resource Owner, so no end-user authorization is needed.

specific types of diagrams are also called a type of flow diagrams

The uses of flow diagrams are vast and honestly endless.

to set up

It is handy to manually generate the diagram from times to times using the previously created command: npm run db:diagram:generate. Though, getting the diagram to update itself on its own automatically without a developer interaction would ensure that it the diagram is never obsolete. There are several ways of doing this.You could use a pre-commit git hook or even better simply configure your CI/CD pipeline(s) to run the npm script whenever something gets merged into the main branch 🙂

When it comes to showing up somewhere in your documentation a diagram describing your SQL database, you often end up with a recurring problem : after a few days / weeks / months, the diagram you made became obsolete.

It would be nice if we could get some official word on whether this repository is affect by the catastrophic CVE-2021-44228 that is currently affecting a considerable percentage of softwares around the globe. From my limited understanding and looking at the refreshingly concise list of dependencies in the pom.xml, I would think this project is not affected, but I and probably others who are not familiar with the projects internals would appreciate an official word.

I understand that typically, it wouldn't make much sense to comment on every CVE that doesn't affect a product, but considering the severity and pervasiveness of this particular issue, maybe an exception is warranted.

What if I hate snakes and/or indifference?

You can also go to the Ruby OAuth Client Library to download the source code and run: 1gem build intuit-oauth.gemspec to build your own gem if you want to modify certain functions in the library.

I agree that these fields should be whitelisted by ActiveAdmin automatically as it generates them via the form helpers. Regardless of if you use :raise or :log you wouldn't usually want these causing unnecessary noise.

Sorbet is written in modern C++ and despite Matz's preferences (quote: "I hate type annotations"), opted for an approach based on type annotations.

I don't think a new tag makes sense here, at least not yet.

Once "Containerfile" starts becoming less of a whisper and more of the topic, then perhaps we can talk about a synonym. But definitely not now.

creating the new tag as a synonym.

Yes, it was right, but nowadays Dockerfiles are not specific to Docker. Dockerfiles also work with Buildah & Podman (and there might be other ones in the future) and they have generalized the naming: “Containerfile.”

Docker suffers from the Xerox problem. Like it or not the industry refers to them as Dockerfiles.

They are 100% identical; just different names. From podman-build: “Builds an image using instructions from one or more Containerfiles or Dockerfiles and a specified build context directory. A Containerfile uses the same syntax as a Dockerfile internally. For this document, a file referred to as a Containerfile can be a file named either ‘Containerfile’ or ‘Dockerfile’.”

how was your code review experience with this merge request? Please tell us how we can continue to iterate and improve: Leave a 👍 or a 👎 on this comment to describe your experience.

Good commit hygiene is considered a best practice. GitLab should encourage and enable these kinds of best practices. This feature currently creates a problem and requires workarounds that remove information, or significant manual work.

Post.in_order_of(:type, %w[Draft Published Archived]).order(:created_at).pluck(:name) which generates SELECT posts.name FROM posts ORDER BY CASE posts.type WHEN 'Draft' THEN 1 WHEN 'Published' THEN 2 WHEN 'Archived' THEN 3 ELSE 4 END ASC, posts.created_at ASC

Changing the second line to: foo.txt text !diff would restore the default unset-ness for diff, while: foo.txt text diff will force diff to be set (both will presumably result in a diff, since Git has presumably not previously been detecting foo.txt as binary).

Unspecified No pattern matches the path, and nothing says if the path has or does not have the attribute, the attribute for the path is said to be Unspecified.

Unset The path has the attribute with special value "false"; this is specified by listing the name of the attribute prefixed with a dash - in the attribute list.

The second situation would be zombie reaping. If the process spawns child processes and does not properly reap them it will lead to a full process table

For both of these concerns we recommend tini. It is incredibly small, has minimal external dependencies, fills each of these roles, and does only the necessary parts of reaping and signal forwarding.

The first being signal handling. If the process launched does not handle SIGTERM by exiting, it will not be killed since it is PID 1 in the container

There are two situations where an init-like process would be helpful for the container.

highly recommended that the resulting image be just one concern per container; predominantly this means just one process per container, so there is no need for a full init system

Try to make the Dockerfile easy to understand/read.

# check for the expected command if [ "$1" = 'mongod' ]; then # init db stuff.... # use gosu (or su-exec) to drop to a non-root user exec gosu mongod "$@" fi # else default to run whatever the user wanted like "bash" or "sh" exec "$@"

A beginning user should be able to docker run official-image bash (or sh) without needing to learn about --entrypoint.

It is also nice for advanced users to take advantage of entrypoint, so that they can docker run official-image --arg1 --arg2 without having to specify the binary to execute.

For dependent packages installed by apt there is not usually a need to pin them to a version.

For example, if using apt to install the main program for the image, be sure to pin it to a specific version (ex: ... apt-get install -y my-package=0.1.0 ...)

Rebuilding the same Dockerfile should result in the same version of the image being packaged, even if the second build happens several versions later, or the build should fail outright, such that an inadvertent rebuild of a Dockerfile tagged as 0.1.0 doesn't end up containing 0.2.3.

Version bumps and security fixes should be attended to in a timely manner.

If you do not represent upstream and upstream becomes interested in maintaining the image, steps should be taken to ensure a smooth transition of image maintainership over to upstream.

Because the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed Dockerfile to ensure that it meets a minimum standard for quality and maintainability. While some of that standard is hard to define (due to subjectivity), as much as possible is defined here, while also adhering to the "Best Practices" where appropriate.

It may be tempting, for the sake of brevity, to put complicated initialization details into a standalone script and merely add a RUN command in the Dockerfile. However, this causes the resulting Dockerfile to be overly opaque

Good question! This is going to be a bit long, so bear with me

Doing everything PID 1 needs to do and nothing else. Things like reading environment files, changing users, process supervision are out of scope for Tini (there are other, better tools for those)

Tini differentiates with:

Finally, do note that there are alternatives to Tini (like Phusion's base image).

As to whether you should be using Tini.

Is whatever process you exec in your entrypoint registering signal handlers? A good way to figure this out might be to check whether your process responds properly to e.g. docker stop (or if it waits for 10 seconds before exiting)

(note: this is not the reason why Jenkins uses Tini, they use it for signal reaping, but it was used in the RabbitMQ image for that reason).

Tini does install explicit signal handlers (to forward them, incidentally), so those signals no longer get dropped. Instead, they're sent to Jenkins, which is not running as PID 1 (Tini is), and therefore has default signal handlers

Second, if Jenkins runs as PID 1, then it may not receive the signals you send it! That's a subtlety in PID 1. Unlike other unlike processes, PID 1 does not have default signal handlers, which means that if Jenkins hasn't explicitly installed a signal handler for SIGTERM, then that signal is going to be discarded when it's sent (whereas the default behavior would have been to terminate the process).

First, if Jenkins runs as PID 1, then it's difficult to differentiate between process that were re-parented to Jenkins (which should be reaped), and processes that were spawned by Jenkins (which shouldn't, because there's other code that's already expecting to wait them).

Tini fixes by "forwarding signals": if you send a signal to Tini, then it sends that same signal to your child process (Jenkins in your case).

A second problem is that once your process has exited, Bash will proceed to exit as well. If you're not being careful, Bash might exit with exit code 0, whereas your process actually crashed (0 means "all fine"; this would cause Docker restart policies to not do what you expect). What you actually want is for Bash to return the same exit code your process had.

Note that you can address this by creating signal handlers in Bash to actually do the forwarding, and returning a proper exit code. On the other hand that's more work, whereas adding Tini is a few lines in your Dockerfile.

In other words, if you use Bash to run Jenkins, and then run docker stop, then Jenkins will never see the stop command!

Now, Bash actually does the same thing (reaping zombies), so you're probably wondering: why not use Bash as PID 1?

When a zombie is created (i.e. which happens when its parent exits, and therefore all chances of it ever being waited by it are gone), it is reparent to init, which is expected to reap it (which means calling wait on it).

In other words, someone has to clean up after "irresponsible" parents that leave their children un-wait'ed, and that's PID 1's job.

Have lost their parent (i.e. their parent exited as well), which means they'll never be waited on by their parent.

Now, unlike other processes, PID 1 has a unique responsibility, which is to reap zombie processes.

Note: This repo does not publish or maintain a latest tag. Please declare a specific tag when pulling or referencing images from this repo.

Unfortunately most init systems don't do this correctly within Docker since they're built for hardware shutdowns instead. This causes processes to be hard killed with SIGKILL, which doesn't give them a chance to correctly deinitialize things.

According to the Unix process model, the init process -- PID 1 -- inherits all orphaned child processes and must reap them. Most Docker containers do not have an init process that does this correctly. As a result, their containers become filled with zombie processes over time.

SIGTSTP is like SIGSTOP except that it can be caught and handled.

Why was the SIGSTOP-ed process not responding to SIGTERM? Why does the kernel keeps it in the same state? Why did it get killed the moment it received the SIGCONT signal? If it was because of the previous SIGTERM signal, where was it kept until the process resumed?

SIGSTOP and SIGKILL are two signals that cannot be caught and handled by a process.

Synchronously waiting for the specific child processes in a (specific) order may leave zombies present longer than the above-mentioned "short period of time"

When a process loses its parent, init becomes its new parent. init periodically executes the wait system call to reap any zombies with init as parent.

or just an uncommon decision to not reap children (see example)

Zombie processes should not be confused with orphan processes: an orphan process is a process that is still executing, but whose parent has died. When the parent dies, the orphaned child process is adopted by init (process ID 1). When orphan processes die, they do not remain as zombie processes; instead, they are waited on by init.

The result is that a process that is both a zombie and an orphan will be reaped automatically.

The term zombie process derives from the common definition of zombie — an undead person. In the term's metaphor, the child process has "died" but has not yet been "reaped". Also, unlike normal processes, the kill command has no effect on a zombie process.

This occurs for the child processes, where the entry is still needed to allow the parent process to read its child's exit status: once the exit status is read via the wait system call, the zombie's entry is removed from the process table and it is said to be "reaped".

A low-level approach is to fork twice, running the desired process in the grandchild, and immediately terminating the child. The grandchild process is now orphaned, and is not adopted by its grandparent, but rather by init.

The process group mechanism in most Unix-like operating systems can be used to help protect against accidental orphaning, where in coordination with the user's shell will try to terminate all the child processes with the "hangup" signal (SIGHUP), rather than letting them continue to run as orphans.

In a Unix-like operating system any orphaned process will be immediately adopted by an implementation-defined system process: the kernel sets the parent to this process

Even though technically the process has a system process as its parent, it is still called an orphan process since the process that originally created it no longer exists.

its jobs (internal representation of process groups)

An init system does not have to be heavyweight. You may be thinking about Upstart, Systemd, SysV init etc with all the implications that come with them. You may be thinking that full system needs to be booted inside the container. None of this is true. A "full init system" as we may call it, is neither necessary nor desirable.

Let's look at a concrete example. Suppose that your container contains a web server that runs a CGI script that's written in bash. The CGI script calls grep. Then the web server decides that the CGI script is taking too long and kills the script, but grep is not affected and keeps running. When grep finishes, it becomes a zombie and is adopted by the PID 1 (the web server). The web server doesn't know about grep, so it doesn't reap it, and the grep zombie stays in the system.

That is, instead of properly reaping adopted processes, it's probably expecting another init process to do that job, and rightly so.

In every day language, people consider "zombie processes" to be simply runaway processes that cause havoc. But formally speaking -- from a Unix operating system point of view -- zombie processes have a very specific definition. They are processes that have terminated but have not (yet) been waited for by their parent processes.

The problems that we solved are applicable to a lot of people. Most people are not even aware of these problems, so things can break in unexpected ways (Murphy's law). It's inefficient if everybody has to solve these problems over and over.

GNU Screen: the prototypical terminal multiplexer

but even ᴡindows® Notepad tries to substitute unknown characters from glyphs in other fonts instead of using the replacement character directly. Sometimes it even substitute characters whereas they exist in the font

How I can know which glyph the font does not support in that list?

Mono doesn't have that glyph, so what you're seeing is that that symbol is being used from another font to be able to show something

find . -regextype posix-extended -regex ".*\.(jpg|gif|png|jpeg)"

That's an important remark. find /path/to/ -iname '*.gif' -o -iname '*.jpg' -print0 will only print the jpg files! You need brackets here: find /path/to/ \( -iname '*.gif' -o -iname '*.jpg' \) -print0

To check whether the music symbol ♫ is being displayed in a string (if it is not being displayed on some devices), you can try measuring the string width; if width == 0 then the symbol is absent.

Checking is done on the entire fallback chain, not just the immediate font referenced." So if you only want to know if it's in the Typeface you specified, this won't work.

I have a custom font which is displaying the box character.

I want to check if the String I am about to display can be displayed by my custom font.

If it cannot then I want to use the standard Android font (which I know can display the characters)

I can't find a method to check if my Typeface can display a particular String though.

Glyph 0 must be assigned to a .notdef glyph. The .notdef glyph is very important for providing the user feedback that a glyph is not found in the font. This glyph should not be left without an outline as the user will only see what looks like a space if a glyph is missing and not be aware of the active font’s limitation.

It is recommended that the shape of the .notdef glyph be either an empty rectangle, a rectangle with a question mark inside of it, or a rectangle with an “X”

You need .notdef, unicode value undefined: microsoft.com/typography/otspec/recom.htm Characters are assigned in blocks of the same kind. Most blocks have some unassigned points at the end to start the next block on a round number. These points allow Unicode Consortium to add new glyphs to a block. New glyphs don't come into existence often. See typophile.com/node/102205. Maybe you can ask your question in the Typophile forum. They can tell you more about how this exactly works and how to render .notdef

I wasn't aware of 'missing character glyph', some Googling suggests that U+0000 can/should be used for missing characters in the font. However in at least one font I've tested with U+0000 is rendered as whitespace while missing characters are rendered as squares (similar to U+25A1).

I want to be able to detect if the font used can display a certain character or not

However after doing a bit of testing I see that this character is not used to represent missing glyphs on either my Windows 7 computer or the Android phone I've tested with (Motorola Atrix).

The Unicode replacement character sounds promising when reading about it on Wikipedia: It is used to indicate problems when a system is not able to render a stream of data to a correct symbol. It is most commonly seen when a font does not contain a character, but is also seen when the data is invalid and does not match any character

Some software attempts to hide this by translating the bytes of invalid UTF-8 to matching characters in Windows-1252 (since that is the most likely source of these errors), so that the replacement character is never seen.

Thus the replacement character is now only seen for encoding errors, such as invalid UTF-8.

At one time the replacement character was often used when there was no glyph available in a font for that character. However, most modern text rendering systems instead use a font's .notdef character, which in most cases is an empty box (or "?" or "X" in a box[5]), sometimes called a "tofu" (this browser displays 􏿾). There is no Unicode code point for this symbol.

Consider a text file containing the German word für (meaning 'for') in the ISO-8859-1 encoding (0x66 0xFC 0x72). This file is now opened with a text editor that assumes the input is UTF-8. The first and last byte are valid UTF-8 encodings of ASCII, but the middle byte (0xFC) is not a valid byte in UTF-8. Therefore, a text editor could replace this byte with the replacement character symbol to produce a valid string of Unicode code points. The whole string now displays like this: "f�r".

2.^ Grey areas indicate non-assigned code points 3.^ Black areas indicate noncharacters (code points that are guaranteed never to be assigned as encoded characters in the Unicode Standard)

The replacement character � (often displayed as a black rhombus with a white question mark) is a symbol found in the Unicode standard at code point U+FFFD in the Specials table. It is used to indicate problems when a system is unable to render a stream of data to a correct symbol.[4] It is usually seen when the data is invalid and does not match any character:

Since the replacement is the same for all errors this makes it impossible to recover the original character. A better (but harder to implement) design is to preserve the original bytes, including the error, and only convert to the replacement when displaying the text. This will allow the text editor to save the original byte sequence, while still showing the error indicator to the user.

No, there is no “glyph not found” character. Different programs use different graphic presentations. An empty narrow rectangle is a common rendering, but not the only one. It could also be a rectangle with a question mark in it or with the code number of the character, in hexadecimal, in it.

The glyph-not-found character is specified by the font engine and by the font; there is no fixed character for it.

While there are many great answers regarding the "glyph not found" glyph, that won't help you actually detect it, as the text string in code will still have the character regardless of the font used to render it.

By the way, I am not talking about � (replacement character). This one is displayed when a Unicode character could not be correctly decoded from a data stream. It does not necessarily produce the same glyph:

replacement glyph

missing glyph

replacement glyph missing glyph interpretable but unrenderable character

There is no standardized look/glyph, it’s up to the implementation

U+25A1 □ WHITE SQUARE may be used to represent a missing ideograph

I have rolled back your edit to Jukka K. Korpela's answer. Please include that information in this answer and/or add a comment to the other answer.

Why not just include the information there and delete this answer?

Then don’t use the phrase “replacement character”, because a) it’s not a character at all, and b) it’s specifically not the character with the Unicode name REPLACEMENT CHARACTER, and c) people easily get confused with issues like this.

it does not have a fixed glyph, though fonts that contain it tend to use very similar glyphs

SVG 1.1 (a W3C Recommendation): The altglyph element provides detailled control over the glyphs used to render particular character data.

anchestor

A character exists, but the glyph to display it isn't available.

The character does not exist. Proposed solutions include encoding the character, markup for individual characters, and Private Use Codepoints.

The character exists in Unicode/ISO 10646, but not in the character encoding used for the document. In this case, use Numeric Character References (NCRs, example: 噸).

However, in some cases, there may be something missing:

Grepping has the problem of "false positives": The output of a pip list | grep NAME would match on any module which name contains "NAME", e.g. also match "some_other_NAME". While pip3 show MODULENAME only matches on complete matches.

To become an international superhero, fork this gist, make a shell-runable node.js application font-to-regexp.js that just takes your font file(s?) on the command line, invokes ttx for you on it(them), loads the result with jsdom, runs fontRange on it and prints the regexp to stdout, instead of doing the above steps manually. Oh, and brag about it in the comments here, of course, so other people find it too!

Note that ttx is part of the fonttools mentioned in the accepted answer. It's a Python script, so it's also available on Mac and Linux.

I've edited the title slightly to make the intent of the question more obvious.

But these two questions are interwoven (and you’ll find many answers to the wrong question in the Answers section).

$ python checkfont.py /usr/share/fonts/**/DejaVuSans.ttf 65 12622 # a ㅎ

The script takes as arguments the font path and optionally code points / characters to search for:

Here is a method using the fontTools Python library (which you can install with something like pip install fonttools):

Type designers usually do not create new characters, i.e. the meanings of those pictures, or, more technically put, ‘the smallest component of written language that has semantic value.’ We don’t invent alphabets, we merely re-interpret existing ones.

Type designers create new glyphs, i.e. pictures representing characters.

Characters versus glyphs

A glyph can also represent more than one character at once. Take an f_f_f ligature as an example. It represents three f characters in a row. Ligatures do not have Unicodes, because the separate characters already have codes and the the fact that it’s a ligature does not change the meaning of its parts.

What if you want to share the same glyph shape between two Unicode values? There are a few situation where you would need that. E.g., the symbol increment U+2206 and the Greek letter Delta U+0394 should look the same. There is a similar issue with Ohm U+2126 and Omega U+03A9. Or, you are creating an all-caps font. Or you simply want to reuse the same space glyph for both the space U+0020 and non-breaking space U+00A0.

Well, actually, some ligatures do have legacy codes, but solely for backwards compatibility with outdated encodings from the long-gone, dark ages of eight-bit computing. E.g. f_f can have the U+FB00 LATIN SMALL LIGATURE FF code point. If ‘eight-bit’ does not tell you anything, please erase everything you read within these parentheses from your memory immediately, keep calm and continue reading.

Here is a method using the fontTools Python library (which you can install with something like pip install fonttools ):

Determine if a glyph exists in a given font