DOC-5419 added commands section

content/commands/command.md

@@ -101,7 +101,7 @@ Command flags are an array. It can contain the following simple strings (status
 * **no_auth:** executing the command doesn't require authentication.
 * **no_async_loading:** the command is denied during asynchronous loading (that is when a replica uses disk-less `SWAPDB SYNC`, and allows access to the old dataset).
 * **no_mandatory_keys:** the command may accept key name arguments, but these aren't mandatory.
-* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "/develop/reference/transactions" >}}).
+* **no_multi:** the command isn't allowed inside the context of a [transaction]({{< relref "develop/using-commands/transactions" >}}).
 * **noscript:** the command can't be called from [scripts]({{< relref "/develop/programmability/eval-intro" >}}) or [functions]({{< relref "/develop/programmability/functions-intro" >}}).
 * **pubsub:** the command is related to [Redis Pub/Sub]({{< relref "/develop/pubsub" >}}).
 * **random**: the command returns random results, which is a concern with verbatim script replication.

content/commands/scan.md

@@ -286,7 +286,7 @@ Also note that this behavior is specific of [`SSCAN`]({{< relref "/commands/ssca
 
 ## Further reading
 
-For more information about managing keys, please refer to the [The Redis Keyspace]({{< relref "/develop/keyspace" >}}) tutorial.
+For more information about managing keys, please refer to the [The Redis Keyspace]({{< relref "/develop/using-commands/keyspace" >}}) tutorial.
 
 ## Additional examples
 

content/develop/ai/search-and-query/best-practices/index-mgmt-best-practices.md

@@ -150,7 +150,7 @@ Monitoring and troubleshooting aliases:
 ## Index maintenance
 
 - If schema changes are required, create a new index with the updated schema and reassign the alias once the index is ready.
-- Use [Redis key expiration]({{< relref "/develop/keyspace#key-expiration" >}}) to automatically remove outdated records and keep indexes lean.
+- Use [Redis key expiration]({{< relref "/develop/using-commands/keyspace#key-expiration" >}}) to automatically remove outdated records and keep indexes lean.
 
 ### FT.ALTER vs. aliasing
 

content/develop/clients/dotnet/condexec.md

@@ -17,7 +17,7 @@ weight: 60
 
 Most Redis client libraries use transactions with the
 [`WATCH`]({{< relref "/commands/watch" >}}) command as the main way to prevent
-two clients writing to the same key at once (see [Transactions]({{< relref "/develop/reference/transactions" >}}) for more information). Unfortunately, this approach is
+two clients writing to the same key at once (see [Transactions]({{< relref "develop/using-commands/transactions" >}}) for more information). Unfortunately, this approach is
 difficult to use explicitly in `NRedisStack`. Its
 [multiplexing]({{< relref "/develop/clients/pools-and-muxing" >}}) system
 is highly efficient and convenient but can also cause bad interactions

content/develop/clients/dotnet/transpipe.md

@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
+    See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -57,7 +57,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/reference/transactions" >}})
+[Transactions]({{< relref "develop/using-commands/transactions" >}})
 for more information about optimistic locking.
 
 The approach to optimistic locking that other clients use

content/develop/clients/go/transpipe.md

@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
+    See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -77,7 +77,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/reference/transactions" >}})
+[Transactions]({{< relref "develop/using-commands/transactions" >}})
 for more information about optimistic locking.
 
 The code below reads a string

content/develop/clients/hiredis/transpipe.md

@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
+    See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -109,5 +109,5 @@ when you have finished processing it, as in the example above.
 you can implement them yourself using the [`MULTI`]({{< relref "/commands/multi" >}}),
 [`EXEC`]({{< relref "/commands/exec" >}}), and [`WATCH`]({{< relref "/commands/watch" >}})
 commands as you would from [`redis-cli`]({{< relref "/develop/tools/cli" >}}).
-See [Transactions]({{< relref "/develop/reference/transactions" >}})
+See [Transactions]({{< relref "develop/using-commands/transactions" >}})
 for more information.

content/develop/clients/jedis/transpipe.md

@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
+    See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -68,7 +68,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/reference/transactions" >}})
+[Transactions]({{< relref "develop/using-commands/transactions" >}})
 for more information about optimistic locking.
 
 The code below reads a string

content/develop/clients/nodejs/transpipe.md

@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
+    See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -112,7 +112,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/reference/transactions" >}})
+[Transactions]({{< relref "develop/using-commands/transactions" >}})
 for more information about optimistic locking.
 
 The code below reads a string

content/develop/clients/pools-and-muxing.md

@@ -71,7 +71,7 @@ used to identify where to send the response data from your commands.
 
 Note that it is not a problem if the multiplexer receives several commands close
 together in time. When this happens, the multiplexer can often combine the commands into a
-[pipeline]({{< relref "/develop/reference/pipelining" >}}), which
+[pipeline]({{< relref "/develop/using-commands/pipelining" >}}), which
 improves efficiency.
 
 Multiplexing offers high efficiency but works transparently without requiring

content/develop/clients/redis-py/transpipe.md

@@ -21,11 +21,11 @@ There are two types of batch that you can use:
 -   **Pipelines** avoid network and processing overhead by sending several commands
     to the server together in a single communication. The server then sends back
     a single communication with all the responses. See the
-    [Pipelining]({{< relref "/develop/reference/pipelining" >}}) page for more
+    [Pipelining]({{< relref "/develop/using-commands/pipelining" >}}) page for more
     information.
 -   **Transactions** guarantee that all the included commands will execute
     to completion without being interrupted by commands from other clients.
-    See the [Transactions]({{< relref "/develop/reference/transactions" >}})
+    See the [Transactions]({{< relref "develop/using-commands/transactions" >}})
     page for more information.
 
 ## Execute a pipeline
@@ -62,7 +62,7 @@ to different keys. The basic idea is to watch for changes to any
 keys that you use in a transaction while you are processing the
 updates. If the watched keys do change, you must restart the updates
 with the latest data from the keys. See
-[Transactions]({{< relref "/develop/reference/transactions" >}})
+[Transactions]({{< relref "develop/using-commands/transactions" >}})
 for more information about optimistic locking.
 
 The example below shows how to repeatedly attempt a transaction with a watched

content/develop/data-types/hashes.md

@@ -101,7 +101,7 @@ See the [complete list of hash commands]({{< relref "/commands/" >}}?group=hash)
 ## Field expiration
 
 New in Redis Open Source 7.4 is the ability to specify an expiration time or a time-to-live (TTL) value for individual hash fields.
-This capability is comparable to [key expiration]({{< relref "/develop/keyspace#key-expiration" >}}) and includes a number of similar commands.
+This capability is comparable to [key expiration]({{< relref "/develop/using-commands/keyspace#key-expiration" >}}) and includes a number of similar commands.
 
 Use the following commands to set either an exact expiration time or a TTL value for specific fields:
 

content/develop/get-started/data-store.md

@@ -82,7 +82,7 @@ You can get a complete overview of available data types in this documentation si
 
 ## Scan the keyspace
 
-Each item within Redis has a unique key. All items live within the Redis [keyspace]({{< relref "/develop/keyspace" >}}). You can scan the Redis keyspace via the [SCAN command]({{< relref "/commands/scan" >}}). Here is an example that scans for the first 100 keys that have the prefix `bike:`:
+Each item within Redis has a unique key. All items live within the Redis [keyspace]({{< relref "/develop/using-commands/keyspace" >}}). You can scan the Redis keyspace via the [SCAN command]({{< relref "/commands/scan" >}}). Here is an example that scans for the first 100 keys that have the prefix `bike:`:
 
 ```
 SCAN 0 MATCH "bike:*" COUNT 100

content/develop/get-started/vector-database.md

@@ -120,7 +120,7 @@ Inspect the structure of one of the bike JSON documents:
 {{< clients-example search_vss dump_data />}}
 
 ### 2. Store the demo data in Redis
-Now iterate over the `bikes`  array to store the data as [JSON]({{< relref "/develop/data-types/json/" >}}) documents in Redis by using the [JSON.SET]({{< relref "commands/json.set/" >}}) command. The below code uses a [pipeline]({{< relref "/develop/reference/pipelining" >}}) to minimize the network round-trip times:
+Now iterate over the `bikes`  array to store the data as [JSON]({{< relref "/develop/data-types/json/" >}}) documents in Redis by using the [JSON.SET]({{< relref "commands/json.set/" >}}) command. The below code uses a [pipeline]({{< relref "/develop/using-commands/pipelining" >}}) to minimize the network round-trip times:
 
 {{< clients-example search_vss load_data />}}
 

content/develop/programmability/_index.md

@@ -61,7 +61,7 @@ Please refer to the following pages for more information:
 * [Redis Functions]({{< relref "/develop/programmability/functions-intro" >}})
 
 When running a script or a function, Redis guarantees its atomic execution.
-The script's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/reference/transactions" >}}).
+The script's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "develop/using-commands/transactions" >}}).
 These semantics mean that all of the script's effects either have yet to happen or had already happened.
 The blocking semantics of an executed script apply to all connected clients at all times.
 

content/develop/programmability/eval-intro.md

@@ -191,7 +191,7 @@ Please consult your client's documentation regarding the specific details.
 
 ### `EVALSHA` in the context of pipelining
 
-Special care should be given executing [`EVALSHA`]({{< relref "/commands/evalsha" >}}) in the context of a [pipelined request]({{< relref "/develop/reference/pipelining" >}}).
+Special care should be given executing [`EVALSHA`]({{< relref "/commands/evalsha" >}}) in the context of a [pipelined request]({{< relref "/develop/using-commands/pipelining" >}}).
 The commands in a pipelined request run in the order they are sent, but other clients' commands may be interleaved for execution between these.
 Because of that, the `NOSCRIPT` error can return from a pipelined request but can't be handled.
 
@@ -229,7 +229,7 @@ These are:
   _1_ means the specific SHA1 is recognized as a script already present in the scripting cache. _0_'s meaning is that a script with this SHA1 wasn't loaded before (or at least never since the latest call to [`SCRIPT FLUSH`]({{< relref "/commands/script-flush" >}})).
 
 * `SCRIPT LOAD script`: this command registers the specified script in the Redis script cache. 
-  It is a useful command in all the contexts where we want to ensure that [`EVALSHA`]({{< relref "/commands/evalsha" >}}) doesn't not fail (for instance, in a pipeline or when called from a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/reference/transactions" >}}), without the need to execute the script.
+  It is a useful command in all the contexts where we want to ensure that [`EVALSHA`]({{< relref "/commands/evalsha" >}}) doesn't not fail (for instance, in a pipeline or when called from a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "develop/using-commands/transactions" >}}), without the need to execute the script.
 
 * [`SCRIPT KILL`]({{< relref "/commands/script-kill" >}}): this command is the only way to interrupt a long-running script (a.k.a slow script), short of shutting down the server.
   A script is deemed as slow once its execution's duration exceeds the configured [maximum execution time]({{< relref "/develop/programmability/#maximum-execution-time" >}}) threshold.
@@ -271,7 +271,7 @@ We call this **script effects replication**.
 starting with Redis 5.0, script effects replication is the default mode and does not need to be explicitly enabled.
 
 In this replication mode, while Lua scripts are executed, Redis collects all the commands executed by the Lua scripting engine that actually modify the dataset.
-When the script execution finishes, the sequence of commands that the script generated are wrapped into a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "/develop/reference/transactions" >}}) and are sent to the replicas and AOF.
+When the script execution finishes, the sequence of commands that the script generated are wrapped into a [`MULTI`]({{< relref "/commands/multi" >}})/[`EXEC`]({{< relref "/commands/exec" >}}) [transaction]({{< relref "develop/using-commands/transactions" >}}) and are sent to the replicas and AOF.
 
 This is useful in several ways depending on the use case:
 

content/develop/programmability/functions-intro.md

@@ -37,7 +37,7 @@ The underlying assumption is that scripts are a part of the application and not
 This approach suits many light-weight scripting use cases, but introduces several difficulties once an application becomes complex and relies more heavily on scripting, namely:
 
 1. All client application instances must maintain a copy of all scripts. That means having some mechanism that applies script updates to all of the application's instances.
-1. Calling cached scripts within the context of a [transaction]({{< relref "/develop/reference/transactions" >}}) increases the probability of the transaction failing because of a missing script. Being more likely to fail makes using cached scripts as building blocks of workflows less attractive.
+1. Calling cached scripts within the context of a [transaction]({{< relref "develop/using-commands/transactions" >}}) increases the probability of the transaction failing because of a missing script. Being more likely to fail makes using cached scripts as building blocks of workflows less attractive.
 1. SHA1 digests are meaningless, making debugging the system extremely hard (e.g., in a [`MONITOR`]({{< relref "/commands/monitor" >}}) session).
 1. When used naively, [`EVAL`]({{< relref "/commands/eval" >}}) promotes an anti-pattern in which scripts the client application renders verbatim scripts instead of responsibly using the [`KEYS` and `ARGV` Lua APIs]({{< relref "/develop/programmability/lua-api#runtime-globals" >}}).
 1. Because they are ephemeral, a script can't call another script. This makes sharing and reusing code between scripts nearly impossible, short of client-side preprocessing (see the first point).
@@ -82,7 +82,7 @@ Functions are also persisted to the AOF file and replicated from master to repli
 When Redis is used as an ephemeral cache, additional mechanisms (described below) are required to make functions more durable.
 
 Like all other operations in Redis, the execution of a function is atomic.
-A function's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "/develop/reference/transactions" >}}).
+A function's execution blocks all server activities during its entire time, similarly to the semantics of [transactions]({{< relref "develop/using-commands/transactions" >}}).
 These semantics mean that all of the script's effects either have yet to happen or had already happened.
 The blocking semantics of an executed function apply to all connected clients at all times.
 Because running a function blocks the Redis server, functions are meant to finish executing quickly, so you should avoid using long-running functions.