Results for contentful-shell

A shell utility wrapper around various Contentful utilities, providing integration with a Rails workflow

Core modules for the Contentful JS SDKs

Client for Contentful's Content Delivery API

Client for Contentful's Content Management API

this tool allows you to export a space to a JSON dump

[](https://www.npmjs.com/package/contentful-resolve-response) [](https://github.com/c

Contentful CLI tool

this tool allows you to import JSON dump exported by contentful-export

Library of useful parsers to use when working with Contentful API responses.

Library modules used by contentful batch utility CLI tools.

Forma 36 Tokens

Migration tooling for contentful

Contentful Content Types (TS Definitions) Generator

React renderer for the Contentful rich text field type.

Forma 36: Form React Components

Forma 36: typography React Component

Forma 36: Button component

Forma 36: utils React Component

Forma 36: Card components

Toolkit for building a Contentful app in React

Forma 36 core

Forma 36: Avatar component

A JavaScript library to develop custom apps for Contentful

Type definitions and constants for the Contentful rich text field type.

pbxplorer is a set of Ruby classes for parsing, editing, and saving Xcode project (.pbxproj) files. It can also be used to explore the contents of a project using the interactive Ruby shell.

PM (PromptManager) parses YAML metadata from markdown strings or files. It expands shell references, extracts metadata and content, and renders ERB templates on demand.

☯️ Bash::Merge provides smart Bash script merging that preserves comments, understands shell structure, and supports freeze blocks for protecting destination content. Perfect for merging configuration scripts and shell templates with customized destination files.

Tool that allows you to reuse static pieces of shell scripts in order to avoid duplication. Esentially, you insert a 'template' tag pointing to a uri containing your snippet and after executing static_shell_templates it will be replaced with the snippet content.

# SecureDataBag / Knife Secure Bag Knife Secure Bag provides a consistent interface to DataBagItem, EncryptedDataBagItem as well as the custom created SecureDataBagItem while also providing a few extra handy features to help in your DataBag workflows. SecureDataBagItem, can not only manage your existing DataBagItems and EncryptedDataBagItems, but it also provides you with a DataBag type which enables you to selectively encrypt only some of the fields in your DataBag thus allowing you to be able to search for the remaining fields. ## Installation To build and install the plugin add it your Gemfile or run: ```shell gem install secure_data_bag ``` ## Configuration #### Knife Secure Bag Defaults for the Knife command may be provided in your _knife.rb_ file. ```ruby knife[:secure_data_bag][:encrypted_keys] = %w( password ssh_keys ssh_ids public_keys private_keys keys secret ) knife[:secure_data_bag][:secret_file] = "#{local_dir}/secret.pem" knife[:secure_data_bag][:export_root] = "#{kitchen_dir}/data_bags" knife[:secure_data_bag][:export_on_upload] = true knife[:secure_data_bag][:defaults][:secrets][:export_format] = 'plain' ``` To break this up: `knife[:secure_data_bag][:encrypted_keys] = []` When Knife Secure Bag encrypts a hash with an _encryption format_ of *nested*, it will recursively walk through the hash from the bottom up and encrypt any key found within this array. `knife[:secure_data_bag][:secret_file]` When encryption is required, the shared secret found at this location will be loaded. `knife[:secure_data_bag][:export_root]` When exporting a data\_bag\_item, files will be created in below this root directory. Typically this would be the data\_bag folder located within your kitchen. `knife[:secure_data_bag][:export_on_upload]` When a data\_bag\_item is edited using `knife secure bag edit`, it may be automatically exported to the _export\_root_. `knife[:secure_data_bag][:defaults][:secrets][:export_format]` The configuration file additionally supports the _defaults_ hash which provides default values for all _command line arguments_ that one might use. Of all of them only the _export\_format_ key is likely to be of much use. ## Examples #### Chef cookbook recipe ```ruby metadata = {} # Define the keys we wish to encrypt metadata[:encrypted_keys] = %w(encoded) # Optionally load a specific shared secret. Otherwise, the global # encrypted\_data\_bag\_secret will be automatically used. secret_key = SecureDataBagItem.load_key("/path/to/secret") # Create a hash of data to use as an exampe raw_data = { id: "item", data_bag: "data_bag", encoded: "my string", unencoded: "other string" } # Instantiate a SecureDataBagItem from a hash item = SecureDataBagItem.from_hash(data, metadata) # Or more explicitely item = SecureDataBagItem.from_hash(data, encrypted_keys: %w(encoded)) # Or load from server item = SecureDataBagItem.load("data_bag", "item") # Print the un-encrypted raw data pp item.raw_data # Print the un-encrypted `encoded` key pp item['encoded'] # Print the encrypted hash as a data_bag_item hash pp item.to_hash =begin { id: "item", data_bag: "data_bag", encoded: { encrypted_data: "encoded", cipher: aes-256-cbc, iv: 13453453dkgfefg== version: 1 } unencoded: "other string", } =end ``` ## Usage #### Knife commands Print an DataBagItem, EncryptedDataBagItem or SecureDataBagItem, auto-detecting the encryption method used as plain text. ```shell knife secure bag show -F js secrets secret_item ``` Print an DataBagItem, EncryptedDataBagItem or SecureDataBagItem, auto-detecting the encryption method used as a SecureDataBagItem in encrypted format. ```shell knife secure bag show -F js secrets secret_item --enc-format nested ``` Edit an EncryptedDataBagItem, preserve it's encryption type, and export a copy to the _data\_bag_ folder in your kitchen. ```shell knife secure bag edit secrets secret_item --export ``` ## Knife SubCommands Most of the SubCommands support the following command-line options: `--enc-format [plain,encrypted,nested]` Ensure that, when displaying or uploading the data\_bag\_item, we forcibly encrypt the data\_bag\_item using the specified format instead of preserving the existing format. In this case: - plain: refers to a DataBagItem - encrypted: refers to an EnrytpedDataBagItem - nested: refers to a SecureDataBagItem `--dec-format [plain,encrypted,nested]` Attempt to decrypt the data\_bag\_item using the given format rather than the auto-detected one. The only real reason to use this is when you wish to specifically select _plain_ as the format so as to not decrypt the item. `--enc-keys key1,key2,key3` Provide a comma delimited list of hash keys which should be encrypted when encrypting the data\_bag\_item. This list will be concatenated with any key names listed in the configuration file or which were previously encrypted. `--export` Export the data\_bag\_item to json file in either of _export-format_ or _enc-format_. `--export-format` Overrides the encryption format only for the _export_ feature. `--export-root` Root directly under which a folder should exist for each _data_bag_ into which to export _data_bag_items_ as json files. When displaying the content of the _data\_bag\_item_, an additional key of *_secure_metadata* will be added to the output which contains gem specific metadata such as the encryption formats and any encrypted keys found. This key will _not_ be saved with the item, however it may be manipulated to alter the behavior of the _edit_ or _export_ commands. #### knife secure bag show DATA_BAG ITEM This command functions just like `knife data bag show` and is used to print out the content of either a DataBagItem, EncryptedDataBagItem or SecureDataBagItem. By default, it will auto-detect the Item type, and print it's unencrypted version to the terminal. This behavior, however, may be altered using the previously mentioned command line options. #### knife secure bag open PATH This commands functions much like `knife secure bag show`, however it is designed to load a _data\_bag\_item_ from disk as opposed to loading it from Chef server. This may be of use when view the content of an exported encrypted file. #### knife secure bag edit DATA_BAG DATA_BAG_ITEM This command functions just like `knife data bag edit` and is used to edit either a DataBagItem, EncryptedDataBagItem or a SecureDataBagItem. It supports all of the same options as `knife secure bag show`. #### knife secure bag from file DATA_BAG PATH This command functions just like `knife data bag from file` and is used to upload either a DataBagItem, EncryptedDataBagItem or a SecureDataBagItem. It supports all of the same options as `knife secure bag show`. ## Recipe DSL The gem additionally provides a few Recipe DSL methods which may be useful. ```ruby load_secure_item = secure_data_bag_item( data_bag_name, data_bag_item, cache: false ) load_plain_item = data_bag_item(data_bag_name, data_bag_item) convert_plain_to_secure = secure_data_bag_item!(load_plain_item) ```

# Quick Start The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS). Let’s assume that the access token provided by your account manager is “TOKEN”. Here’s how to get the list of ids of all your invoices from the first week of August with a shell script: ```bash query="end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00" curl -i "https://api-eu.getaround.com/owner/v1/invoices?${query}" \ -H "Authorization: Bearer TOKEN" \ -H "Accept:application/json" \ -H "Content-Type:application/json" ``` And here’s how to get the invoice with the id 12345: ```bash curl -i "https://api-eu.getaround.com/owner/v1/invoices/12345" \ -H "Authorization: Bearer TOKEN" \ -H "Accept: application/json" \ -H "Content-Type: application/json"" ``` See the [endpoints section](#tag/Invoices) of this guide for details about the response format. Dates in request params should follow the ISO 8601 standard. # Authentication All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager. Unauthenticated requests will return a 401 status. # Pagination The page number and the number of items per page can be set with the “page” and “per_page” params. For example, this request will return the second page of invoices, and 50 invoices per page: `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` Both of these params are optional. The default page size is 30 items. The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page. Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel="next" ``` # Throttling policy and Date range limitation We have throttling policy that prevents you to perform more than 100 requests per min from the same IP. Also, there is a limitation on the size of the range of dates given in params in some requests. All requests that need start_date and end_date, do not accept a range bigger than 30 days. # Webhooks Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations. ### Setup To set up an endpoint, you need to define a route on your server for receiving events, and then <a href="mailto:owner-api@getaround.com">ask Getaround</a> to add this URL to your account. To acknowledge receipt of a event, your endpoint must: - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate. ### Testing Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below: <form action="/docs/api/owner/fire_ping_webhook" method="post"><input type="submit" value="Send Ping Event"></form> You should receive the following JSON payload: ```json { "data": { "ping": "pong" }, "type": "ping", "occurred_at": "2019-04-18T08:30:05Z" } ``` ### Retries Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned. ### Verifying Signatures Getaround will also provide you with a secret token, which is used to create a hash signature with each payload. This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this: ```ruby require 'sinatra' require 'json' post '/payload' do push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end ``` The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this: ```ruby post '/payload' do request.body.rewind payload_body = request.body.read verify_signature(payload_body) push = JSON.parse(params[:payload]) "I got some JSON: #{push.inspect}" end def verify_signature(payload_body) signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body) return halt 500, "Signatures didn't match!" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ``` Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however: No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body. Using a plain `==` operator is not advised. A method like secure_compare performs a "constant time" string comparison, which renders it safe from certain timing attacks against regular equality operators. ### Best Practices - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering.

== Confidently Build Terminal Apps Rooibos[https://rooibos.run] helps you build interactive terminal applications. Keep your code understandable and testable as it scales. Rooibos handles keyboard, mouse, and async work so you can focus on behavior and user experience. gem install rooibos <i>Currently in beta. APIs may change before 1.0.</i> === Get Started in Seconds rooibos new my_app cd my_app rooibos run That's it. You have a working app with keyboard navigation, mouse support, and clickable buttons. Open <tt>lib/my_app.rb</tt> to make it your own. --- === The Pattern \Rooibos uses Model-View-Update, the architecture behind Elm[https://guide.elm-lang.org/architecture/], Redux[https://redux.js.org/], and {Bubble Tea}[https://github.com/charmbracelet/bubbletea]. State lives in one place. Updates flow in one direction. The runtime handles rendering and runs background work for you. --- === Hello, MVU The simplest \Rooibos app. Press any key to increment the counter. Press <tt>Ctrl</tt>+<tt>C</tt> to quit. require "rooibos" module Counter # Init: How do you create the initial model? Init = -> { 0 } # View: What does the user see? View = -> (model, tui) { tui.paragraph(text: <<~END) } Current count: #{model}. Press any key to increment. Press Ctrl+C to quit. END # Update: What happens when things change? Update = -> (message, model) { if message.ctrl_c? Rooibos::Command.exit elsif message.key? model + 1 end } end Rooibos.run(Counter) That's the whole pattern: Model holds state, Init creates it, View renders it, and Update changes it. The runtime handles everything else. --- === Your First Real Application A file browser in sixty lines. It opens files, navigates directories, handles errors, styles directories and hidden files differently, and supports vim-style keyboard shortcuts. If you can do this much with this little code, imagine how easy _your_ app will be to build. require "rooibos" module FileBrowser # Model: What state does your app need? Model = Data.define(:path, :entries, :selected, :error) Init = -> { path = Dir.pwd entries = Entries[path] Ractor.make_shareable( # Ensures thread safety Model.new(path:, entries:, selected: entries.first, error: nil)) } View = -> (model, tui) { tui.block( titles: [model.error || model.path, { content: KEYS, position: :bottom, alignment: :right}], borders: [:all], border_style: if model.error then tui.style(fg: :red) else nil end, children: [tui.list(items: model.entries.map(&ListItem[model, tui]), selected_index: model.entries.index(model.selected), highlight_symbol: "", highlight_style: tui.style(modifiers: [:reversed]))] ) } Update = -> (message, model) { return model.with(error: ERROR) if message.error? model = model.with(error: nil) if model.error && message.key? if message.ctrl_c? || message.q? then Rooibos::Command.exit elsif message.home? || message.g? then model.with(selected: model.entries.first) elsif message.end? || message.G? then model.with(selected: model.entries.last) elsif message.up_arrow? || message.k? then Select[:-, model] elsif message.down_arrow? || message.j? then Select[:+, model] elsif message.enter? then Open[model] elsif message.escape? then Navigate[File.dirname(model.path), model] end } private # Lines below this are implementation details KEYS = "↑/↓/Home/End: Select | Enter: Open | Esc: Navigate Up | q: Quit" ERROR = "Sorry, opening the selected file failed." ListItem = -> (model, tui) { -> (name) { modifiers = name.start_with?(".") ? [:dim] : [] fg = :blue if name.end_with?("/") tui.list_item(content: name, style: tui.style(fg:, modifiers:)) } } Select = -> (operator, model) { new_index = model.entries.index(model.selected).public_send(operator, 1) model.with(selected: model.entries[new_index.clamp(0, model.entries.length - 1)]) } Open = -> (model) { full = File.join(model.path, model.selected.delete_suffix("/")) model.selected.end_with?("/") ? Navigate[full, model] : Rooibos::Command.open(full) } Navigate = -> (path, model) { entries = Entries[path] model.with(path:, entries:, selected: entries.first, error: nil) } Entries = -> (path) { Dir.children(path).map { |name| File.directory?(File.join(path, name)) ? "#{name}/" : name }.sort_by { |name| [name.end_with?("/") ? 0 : 1, name.downcase] } } end Rooibos.run(FileBrowser) --- === Batteries Included ==== Commands Applications fetch data, run shell commands, and set timers. \Rooibos Commands run off the main thread and send results back as messages. <b>HTTP requests:</b> Update = -> (message, model) { case message in :fetch_users [model.with(loading: true), Rooibos::Command.http(:get, "/api/users", :got_users)] in { type: :http, envelope: :got_users, status: 200, body: } model.with(loading: false, users: JSON.parse(body)) in { type: :http, envelope: :got_users, status: } model.with(error: "HTTP #{status}") end } <b>Shell commands:</b> Update = -> (message, model) { case message in :list_files Rooibos::Command.system("ls -la", :listed_files) in { type: :system, envelope: :listed_files, stdout:, status: 0 } model.with(files: stdout.lines.map(&:chomp)) in { type: :system, envelope: :listed_files, stderr:, status: } model.with(error: stderr) end } <b>Timers:</b> Update = -> (message, model) { case message in { type: :timer, envelope: :tick, elapsed: } [model.with(frame: model.frame + 1), Rooibos::Command.wait(1.0 / 24, :tick)] end } <b>And more!</b> \Rooibos includes <tt>all</tt>, <tt>batch</tt>, <tt>bubble</tt>, <tt>cancel</tt>, <tt>custom</tt>, <tt>deliver</tt>, <tt>exit</tt>, <tt>http</tt>, <tt>map</tt>, <tt>open</tt>, <tt>system</tt>, <tt>tick</tt>, and <tt>wait</tt> commands. You can also define your own custom commands for complex orchestration. Every command produces a message, and Update handles it the same way. ==== Testing \Rooibos makes TUIs so easy to test, you'll save more time by writing tests than by not testing. <b>Unit test Update, View, and Init.</b> No terminal needed. Test helpers included. def test_moves_selection_down_with_j model = Ractor.make_shareable(FileBrowser::Model.new( path: "/", entries: %w[bin exe lib], selected: "bin", error: nil)) message = RatatuiRuby::Event::Key.new(code: "j") result = FileBrowser::Update.call(message, model) assert_equal "exe", result.selected end <b>Style assertions.</b> Draw to a headless terminal, verify colors and modifiers. def test_directories_are_blue with_test_terminal(60, 10) do model = Ractor.make_shareable(FileBrowser::Model.new( path: "/", entries: %w[file.txt subdir/], selected: "file.txt", error: nil)) widget = FileBrowser::View.call(model, RatatuiRuby::TUI.new) RatatuiRuby.draw { |frame| frame.render_widget(widget, frame.area) } assert_blue(1, 2) # "subdir/" at column 1, row 2 end end <b>System tests.</b> Inject events, run the full app, snapshot the result. def test_selection_moves_down with_test_terminal(120, 30) do Dir.mktmpdir do |dir| FileUtils.touch(File.join(dir, "a")) FileUtils.touch(File.join(dir, "b")) FileUtils.touch(File.join(dir, "c")) inject_key(:down) inject_key(:ctrl_c) # Tests use explicit params to inject deterministic initial state. Rooibos.run( model: Ractor.make_shareable(FileBrowser::Model.new( path: dir, entries: %w[a b c], selected: "a", error: nil)), view: FileBrowser::View, update: FileBrowser::Update ) assert_snapshots("selection_moved_down") do |lines| title = "┌/tmp/test#{'─' * 107}┐" lines.map do |l| l.gsub(/┌#{Regexp.escape(dir)}[^┐]*┐/, title) end end end end end Snapshots record both plain text and ANSI colors. Normalization blocks mask dynamic content (timestamps, temp paths) for cross-platform reproducibility. Run <tt>UPDATE_SNAPSHOTS=1 rake test</tt> to regenerate baselines. ==== Scale Up Large applications decompose into fragments. Each fragment has its own Model, View, Update, and Init. Parents compose children. The pattern scales. The Router DSL eliminates boilerplate: module Dashboard include Rooibos::Router route :stats, to: StatsPanel route :network, to: NetworkPanel receive_events :ctrl_c, -> { Rooibos::Command.exit } only when: -> (_message, model) { !model.modal_open } do receive_events :q, -> { Rooibos::Command.exit } forward_events :s, to: :stats, as: :fetch forward_events :p, to: :network, as: :ping end Update = from_router # ... Model, Init, View below end Declare routes and event handlers. The router generates Update for you. Use guards to ignore messages when needed. ==== CLI The <tt>rooibos</tt> command scaffolds projects and runs applications. rooibos new my_app # Generate project structure rooibos run # Run the app in current directory Generated apps include tests, type signatures, and a working welcome screen with keyboard and mouse support. --- === The Ecosystem \Rooibos builds on RatatuiRuby[https://www.ratatui-ruby.dev], a Rubygem built on Ratatui[https://ratatui.rs]. You get native performance with the joy of Ruby. \Rooibos is one way to manage state and composition. Kit is another. ==== Rooibos[https://www.rooibos.run] Model-View-Update architecture. Inspired by Elm, Bubble Tea, and React + Redux. Your UI is a pure function of state. - Functional programming with MVU - Commands work off the main thread - Messages, not callbacks, drive updates ==== {Kit}[https://sr.ht/~kerrick/ratatui_ruby/#chapter-3-the-object-path--kit] (Coming Soon) Component-based architecture. Encapsulate state, input handling, and rendering in reusable pieces. - OOP with stateful components - Separate UI state from domain logic - Built-in focus management & click handling Both use the same widget library and rendering engine. Pick the paradigm that fits your brain. --- === Links [Get Started] {Getting Started}[https://www.rooibos.run/docs/trunk/doc/getting_started/index_md.html], {Tutorial}[https://www.rooibos.run/docs/trunk/doc/tutorial/index_md.html], {Examples}[https://www.rooibos.run/docs/trunk/examples/app_fractal_dashboard/README_md.html] [Coming From...] {React/Redux}[https://www.rooibos.run/docs/trunk/doc/getting_started/for_react_developers_md.html], {BubbleTea}[https://www.rooibos.run/docs/trunk/doc/getting_started/for_go_developers_md.html], {Textual}[https://www.rooibos.run/docs/trunk/doc/getting_started/for_python_developers_md.html] [Learn More] {Essentials}[https://www.rooibos.run/docs/trunk/doc/essentials/index_md.html], {Scaling Up}[https://www.rooibos.run/docs/trunk/doc/scaling_up/index_md.html], {Best Practices}[https://www.rooibos.run/docs/trunk/doc/best_practices/index_md.html], {Troubleshooting}[https://www.rooibos.run/docs/trunk/doc/troubleshooting/index_md.html] [Community] {Forum}[https://forum.setdef.com/c/rooibos], {Announcements}[https://forum.setdef.com/tags/c/rooibos/announcement], {Bug Tracker}[https://forum.setdef.com/tags/c/rooibos/bug], {Contribution Guide}[https://github.com/setdef/Rooibos/blob/trunk/CONTRIBUTING.md], {Code of Conduct}[https://github.com/setdef/Rooibos/blob/trunk/CODE_OF_CONDUCT.md] --- [Website] https://rooibos.run [Source] https://github.com/setdef/Rooibos [RubyGems] https://rubygems.org/gems/rooibos © 2026 Kerrick Long · Library: LGPL-3.0-or-later · Website: CC-BY-NC-ND-4.0 · Snippets: MIT-0