@@ -866,9 +866,10 @@ def add(args)
866
866
# operations in order.
867
867
#
868
868
# Each of the operations appearing in the Array must itself be an Array
869
- # with exactly three elements: an operator:: must be :add, :replace, or
870
- # :delete an attribute name:: the attribute name (string or symbol) to
871
- # modify a value:: either a string or an array of strings.
869
+ # with exactly three elements:
870
+ # an operator :: must be :add, :replace, or :delete
871
+ # an attribute name :: the attribute name (string or symbol) to modify
872
+ # a value :: either a string or an array of strings.
872
873
#
873
874
# The :add operator will, unsurprisingly, add the specified values to the
874
875
# specified attribute. If the attribute does not already exist, :add will
@@ -911,13 +912,13 @@ def add(args)
911
912
# may not get extended information that will tell you which one failed.
912
913
# #modify has no notion of an atomic transaction. If you specify a chain
913
914
# of modifications in one call to #modify, and one of them fails, the
914
- # preceding ones will usually not be "rolled back, " resulting in a
915
+ # preceding ones will usually not be "rolled back", resulting in a
915
916
# partial update. This is a limitation of the LDAP protocol, not of
916
917
# Net::LDAP.
917
918
#
918
919
# The lack of transactional atomicity in LDAP means that you're usually
919
920
# better off using the convenience methods #add_attribute,
920
- # #replace_attribute, and #delete_attribute, which are are wrappers over
921
+ # #replace_attribute, and #delete_attribute, which are wrappers over
921
922
# #modify. However, certain LDAP servers may provide concurrency
922
923
# semantics, in which the several operations contained in a single #modify
923
924
# call are not interleaved with other modification-requests received
0 commit comments